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Abstract: This standard specifies the air interface of fixed broadband wireless access (BWA) 
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Introduction 



(This introduction is not part of IEEE Std 802.16-2004, IEEE Standard for Local and metropolitan area 
networks— Part 16: Air Interface for Fixed Broadband Wireless Access Systems.) 



This standard specifies the air interface of fixed broadband wireless access (BWA) systems supporting 
multimedia services. The medium access control layer (MAC) supports a primarily point-to- multipoint 
architecture, with an optional mesh topology. The MAC is structured to support multiple physical layer (PHY) 
specifications, each suited to a particular operational environment. For operational frequencies from 10-66 
GHz, the WirelessMAN-SC PHY, based on single-carrier modulation, is specified. For frequencies below 11 
GHz! where propagation without a direct line of sight must be accommodated, three alternatives are provided: 
WirelessMAN-OFDM (using orthogonal frequency-division multiplexing), WirelessMAN-OFDMA (using 
orthogonal frequency-division multiple access), and WirelessMAN-SCa (using single-carrier modulation). 
This standards revises and consolidates IEEE Standards 802.16-2001, 802.16a-2003, and 802.16c-2002. 
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conducting inquiries into the legal validity or scope of those patents that are brought to its attention. A patent 
holder or patent applicant has filed a statement of assurance that it will grant licenses under these rights 
without compensation or under reasonable rates and nondiscriminatory, reasonable terms and conditions to 
applicants desiring to obtain such licenses. The IEEE makes no representation as to the reasonableness of 
rates, terms, and conditions of the license agreements offered by patent holders or patent applicants. Further 
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Notice to users 



Errata 

Errata, if any, for this and all other standards can be accessed at the following URL: httpj// 
standards.ieee.org/reading/ieee/updates/err ata/index.html. Users are encouraged to check this URL for 
errata periodically. 



Interpretations 
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index.html. 
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IEEE Standard for 

Local and metropolitan area networks 

Part 16: Air Interface for Fixed 
Broadband Wireless Access Systems 

1 . Overview 

1.1 Scope 

This revised standard specifies the air interface, including the medium access control layer and multiple 
physical layer specifications, of fixed BWA systems supporting multiple services. It consolidates IEEE Std 
802.16™, IEEE Std 802.16a™, and IEEE Std 802.16c™, retaining all modes and major features without 
adding modes. Content is added or revised to improve performance, ease deployment, or replace incorrect, 
ambiguous, or incomplete material, including system profiles. 

1.2 Purpose 

This standard enables rapid worldwide deployment of innovative, cost-effective, and interoperable multi- 
vendor BWA products, facilitates competition in broadband access by providing alternatives to wireline 
broadband access, encourages worldwide spectrum allocation, and accelerates the commercialization of 
BWA systems. 

1.3 Frequency bands 

The applications depend on the spectrum to be used. The primary bands of interest are as follows: 
1.3.1 10-66 GHz licensed bands 

The 10-66 GHz bands provide a physical environment where, due to the short wavelength, line-of-sight 
(LOS) is required and multipath is negligible. In the 10-66 GHz band, channel bandwidths of 25 MHz or 28 
MHz are typical. With raw data rates in excess of 120 Mb/s, this environment is well suited for PMP access 
serving applications from small office/home office (SOHO) through medium to large office applications. 

The single-carrier modulation air interface specified herein for 10-66 GHz shall be known as the 
"WirelessMAN-SC®" air interface. 
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1.3.2 Frequencies below 11 GHz 

Frequencies below 11 GHz provide a physical environment where, due to the longer wavelength, LOS is not 
necessary and multipath may be significant. The ability to support near-LOS and non-LOS (NLOS) 
scenarios requires additional PHY functionality, such as the support of advanced power management 
techniques, interference mitigation/coexistence, and multiple antennas. 

Additional MAC features such as mesh topology and automatic repeat request (ARQ) are introduced. 

1.3.3 License-exempt frequencies below 11 GHz (primarily 5-6 GHz) 

The physical environment for the license-exempt bands below 11 GHz is similar to that of the licensed 
bands in the same frequency range, as described in 1.3.2. However, the license-exempt nature introduces 
additional interference and co-existence issues, whereas regulatory constraints limit the allowed radiated 
power. In addition to the features described in 1.3.2, the PHY and MAC introduce mechanisms such as 
dynamic frequency selection (DFS) to detect and avoid interference. 

1 .3.4 Air interface nomenclature and PHY compliance 

Table 1 summarizes the nomenclature for the various air interface specifications in this standard. 



Table 1— Air interface nomenclature 



Designation 


Applicability 


PHY 


Additional 
MAC 
requirements 


Options 


Duplexing 
alternative 


WirelessMAN-SC™ 


10-66 GHz 


8.1 






TDD 
FDD 


WirelessMAN-SCa™ 


Below 11 GHz 
licensed bands 


8.2 




AAS (6.3.7.6) 
ARQ (6.3.4) 
STC (8.2.1.4.3) 


TDD 
FDD 


WirelessMAN-OFDM™ 


Below 11 GHz 
licensed bands 


8.3 




AAS (6.3.7.6) 
ARQ (6.3.4) 
Mesh (6.3.6.6) 
STC (8.3.8) 


TDD 
FDD 


WirelessMAN-OFDMA 


Below 11 GHz 
licensed bands 


8.4 




AAS (6.3.7.6) 
ARQ (6.3.4) 
STC (8.4.8) 


TDD 
FDD 


WirelessHUMAN™ 


Below 11 GHz 
license-exempt 
bands 


[8.2, 8.3, 
or 8.4] 
and 8.5 


DFS (6.3.15) 


AAS (6.3.7.6) 
ARQ (6.3.4) 
Mesh (6.3.6.6) 
(with 8.3 only) 
STC (8.2.1.4.3/8.3.8/ 
8.4.8) 


TDD 



All implementations of this standard shall comply with the requirements of Clause 6 and Clause 7. 

Implementations of this standard for any applicable frequencies between 10 GHz and 66 GHz shall comply 
with the WirelessMAN-SC PHY as described in 8.1. 



2 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



lEEEStd 802.16-2004 



Implementations of this standard for licensed frequencies below 11 GHz (such as those listed in B.l) shall 
either comply with the WirelessMAN-SCa PHY as described in 8.2, the WirelessMAN-OFDM PHY as 
described in 8.3, the WirelessM AN -OFDM A PHY as described in 8.4, or the WirelessMAN-SC PHY as 
described in 8.1 for licensed frequencies above 10 GHz. 

Implementations of this standard for license-exempt frequencies below 1 1 GHz (such as those listed in B.l) 
shall comply with the WirelessMAN-SCa PHY as described in 8.2, the WirelessMAN-OFDM PHY as 
described in 8.3, or the WirelessMAN-OFDMA PHY as described in 8.4. They shall further comply with the 
DFS protocols (6.3.15) and with 8.5. 



1.4 Reference model 



Figure 1 illustrates the reference model and scope of this standard. 

The MAC comprises three sublayers. The Service-Specific Convergence Sublayer (CS) provides any 
transformation or mapping of external network data, received through the CS service access point (SAP); 
into MAC SDUs received by the MAC Common Part Sublayer (CPS) through the MAC SAP. This includes 
classifying external network service data units (SDUs) and associating them to the proper MAC service flow 
identifier (SFID) and connection identifier (CID). It may also include such functions as pay load header 
suppression (PHS). Multiple CS specifications are provided for interfacing with various protocols. The 
internal format of the CS payload is unique to the CS, and the MAC CPS is not required to understand the 
format of or parse any information from the CS payload. 

Scope of standard 



< 

s 



C CS SAP ) - 

Service-Specific 
Convergence Sublayer 
(CS) 



( MAC SAP ) 

MAC Common Part Sublayer 
(MAC CPS) 



Security Sublayer 



PHY SAP 



Physical Layer 
(PHY) 



Management Entity 

Service-Specific 
Convergence Sublayers 



_»» Management Entity 
MAC Common Part Sublayer 



Security Sublayer 



Management Entity 
PHY 



Data/Control Plane 



Management Plane 




Figure 1— IEEE Std 802.16 protocol layering, showing SAPs 
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The MAC CPS provides the core MAC functionality of system access, bandwidth allocation, connection 
establishment, and connection maintenance. It receives data from the various CSs, through the MAC SAP, 
classified to particular MAC connections. An example of MAC CPS service definition is given in Annex C 
Quality of Service (QoS) is applied to the transmission and scheduling of data over the PHY. 

The MAC also contains a separate security sublayer providing authentication, secure key exchange, and 
encryption. 

Data, PHY control, and statistics are transferred between the MAC CPS and the PHY via the PHY SAP 
(which is implementation specific). 

The PHY definition includes multiple specifications, each appropriate to a particular frequency range and 
application. The various PHY specifications supported are discussed in Clause 8. 



4 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



lEEEStd 802.16-2004 
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6 IEEE standards referred to in Clause 2 are trademarks owned by the Institute of Electrical and Electronics Engineers, Incorporated. 
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3. Definitions 

For the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary of 
IEEE Standards Terms, Seventh Edition [B23], 10 should be referenced for terms not defined in this clause. 

3.1 adaptive antenna system (AAS): A system adaptively exploiting more than one antenna to improve the 
coverage and the system capacity. 

3.2 adaptive modulation: A system's ability to communicate with another system using multiple burst 
profiles and a system's ability to subsequently communicate with multiple systems using different burst 
profiles. 

3.3 automatic repeat request (ARQ) block: A distinct unit of data that is carried on an ARQ-enabled 
connection. Such a unit is assigned a sequence number, and is managed as a distinct entity by the ARQ state 
machines. Block size is a parameter negotiated during connection establishment. 

3.4 bandwidth stealing: The use, by a subscriber station (SS), of a portion of the bandwidth allocated in 
response to a Bandwidth Request for a connection to send another Bandwidth Request rather than sending 
data. 

3.5 base station (BS): A generalized equipment set providing connectivity, management, and control of the 
subscriber station (SS). 

3.6 basic connection: Connection that is established during subscriber station (SS) initial ranging and used 
to transport delay-intolerant medium access control (MAC) management messages. 

3.7 broadband: Having instantaneous bandwidths greater than around 1 MHz and supporting data rates 
greater than about 1.5 Mb/s. 

3.8 broadband wireless access (BWA): Wireless access in which the connection(s) capabilities are 
broadband. 

3.9 burst profile: Set of parameters that describe the uplink or downlink transmission properties associated 
with an interval usage code. Each profile contains parameters such as modulation type, forward error 
correction (FEC) type, preamble length, guard times, etc. See also: interval usage code. 

3.10 channel identifier (ChID): An identifier used to distinguish between multiple uplink channels, all of 
which are associated with the same downlink channel. 

3.11 concatenation: The act of combining multiple medium access control (MAC) protocol data units 
(PDUs) into a single PHY SDU. 

3.12 connection: A unidirectional mapping between base station (BS) and subscriber station (SS) medium 
access control (MAC) peers for the purpose of transporting a service flow's traffic. Connections are 
identified by a connection identifier (CID). All traffic is carried on a connection, even for service flows that 
implement connectionless protocols, such as Internet Protocol (IP). See also: connection identifier. 

3.13 connection identifier (CID): A 16-bit value that identifies a connection to equivalent peers in the MAC 
of the base station (BS) and subscriber station (SS). It maps to a service flow identifier (SFID), which 
defines the Quality of Service (QoS) parameters of the service flow associated with that connection. 
Security associations (SAs) also exist between keying material and CIDs. See also: service flow identifier. 



l0 The numbers in brackets correspond to those of the bibliography in Annex A. 
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3 14 DC subcarrier: In an orthogonal frequency division multiplexing (OFDM) or orthogonal frequency 
division multiple access (OFDMA) signal, the subcarrier whose frequency would be equal to the RF center 
frequency of the station. 

3.15 directed mesh (DM): The realization of a physical mesh using substantially directional antennas. See 
also: mesh. 

3.16 downlink: The direction from the base station (BS) to the subscriber station (SS). 

3.17 downlink burst transition gap (DLBTG): Gap included on the trailing edge of each allocated down- 
link burst so that ramp down can occur and delay spread can clear receivers. 

3.18 downlink channel descriptor (DCD): A MAC message that describes the PHY characteristics of a 
downlink channel. 

3.19 downlink interval usage code (DIUC): An interval usage code specific to a downlink. See also: 
interval usage code. 

3 20 downlink map (DL-MAP): A MAC message that defines burst start times for both time division 
multiplex and time division multiple access (TDMA) by a subscriber station (SS) on the downlink. 

3.21 dynamic frequency selection (DFS): The ability of a system to switch to different physical RF 
channels between transmit and receive activity based on channel measurement criteria. 

3.22 dynamic service: The set of messages and protocols that allow the base station (BS) and subscriber 
station (SS) to add, modify, or delete the characteristics of a service flow. 

3.23 fixed wireless access: Wireless access application in which the location of the base station (BS) and 
subscriber station (SS) are fixed in location during operation. 

3.24 frame: A structured data sequence of fixed duration used by some PHY specifications. A frame may 
contain both an uplink subframe and a downlink subframe. 

3.25 frequency division duplex (FDD): A duplex scheme in which uplink and downlink transmissions use 
different frequencies but are typically simultaneous. 

3 26 frequency offset index: An index number identifying a particular subcarrier in an orthogonal 
frequency division multiplexing (OFDM) or orthogonal frequency division multiple access (OFDMA) 
signal, which is related to its subcarrier index. Frequency offset indices may be positive or negative. 

3.27 initial ranging connection identifier: A well-known CID that is used by a subscriber station (SS) 
during the initial ranging process. This CID is defined as constant value within the protocol since an SS has 
no addressing information available until the initial ranging process is complete. 

3.28 interval usage code: A code identifying a particular burst profile that can be used by a downlink or 
uplink transmission interval. 

3.29 mesh (MSH): Network architecture, wherein systems are capable of forwarding traffic from and to 
multiple other systems. 

3.30 minislot: A unit of uplink bandwidth allocation equivalent to n physical slots (PSs), where n = 2 m and 
m is an integer ranging from 0 through 7. 
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3.31 multicast polling group: A group of zero or more subscriber stations (SSs) that are assigned a 
multicast address for the purposes of polling. 

3.32 node: A term associated with a mesh network station. A node, due to the nature of mesh, may behave as 
a BS, SS, or both, and will generate and forward data to other nodes. 

3.33 packing: The act of combining multiple service data units (SDUs) from a higher layer into a single 
medium access control protocol data unit (PDU). 

3.34 payload header suppression (PHS): The process of suppressing the repetitive portion of payload 
headers at the sender and restoring the headers at the receiver. 

3.35 payload header suppression field (PHSF): A string of bytes representing the header portion of a 
protocol data unit (PDU) in which one or more bytes are to be suppressed (i.e., a snapshot of the 
uncompressed PDU header inclusive of suppressed and unsuppressed bytes). 

3.36 payload header suppression index (PHSI): An 8-bit mask that indicates which bytes in the Payload 
Header Suppression Field (PHSF) to suppress and which bytes to not suppress. 

3.37 payload header suppression size (PHSS): The length of the suppressed field in bytes. This value is 
equivalent to the number of bytes in the Payload Header Suppression Field (PHSF) and also the number of 
valid bits in the Payload Header Suppression Mask (PHSM). 

3.38 payload header suppression valid (PHSV): A flag that tells the sending entity to verify all bytes that 
are to be suppressed. 

3.39 physical slot (PS): A unit of time, dependent on the PHY specification, for allocating bandwidth 

3.40 point to point (PtP): A mode of operation whereby a link exists between two network entities. 

3.41 primary management connection: A connection that is established during initial subscriber station 
(SS) ranging and used to transport delay-tolerant medium access control (MAC) management messages. 

3.42 privacy key management (PKM) protocol: A client/server model between the base station (BS) and 
subscriber station (SS) that is used to secure distribution of keying material. 

3.43 protocol data unit (PDU): The data unit exchanged between peer entities of the same protocol layer. 
On the downward direction, it is the data unit generated for the next lower layer. On the upward direction, it 
is the data unit received from the previous lower layer (see Figure 2). 

3.44 RF center frequency: The center of the frequency band in which a base station (BS) or SS is intended 
to transmit. 

3.45 receive/transmit transition gap (RTG): A gap between the uplink burst and the subsequent downlink 
burst in a time division duplex (TDD) transceiver. This gap allows time for the base station (BS) to switch 
from receive to transmit mode and SSs to switch from transmit to receive mode. During this gap, the BS and 
SS are not transmitting modulated data but simply allowing the BS transmitter carrier to ramp up, the 
transmit/receive (Tx/Rx) antenna switch to actuate, and the SS receiver sections to activate. Not applicable 
for FDD systems. 

3.46 secondary management connection: A connection that may be established during subscriber station 
(SS) registration that is used to transport standards-based (SNMP, DHCP, etc.) messages. 
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Figure 2— PDU and SDU in a protocol stack 

3.47 security association (SA): The set of security information a base station (BS) and one or more of its 
client subscriber stations (SSs) share in order to support secure communications. This shared information 
includes traffic encryption keys (TEKs) and cipher block chaining (CBC) initialization vectors. 

3.48 security association identifier (SAID): An identifier shared between the base station (BS) and 
subscriber station that uniquely identifies a security association (SA). 

3.49 service access point (SAP): The point in a protocol stack where the services of a lower layer are 
available to its next higher layer. 

3.50 service data unit (SDU): The data unit exchanged between two adjacent protocol layers. On the 
downward direction, it is the data unit received from the previous higher layer. On the upward direction, it is 
the data unit sent to the next higher layer (see Figure 2). 

3.51 service flow (SF): A unidirectional flow of medium access control (MAC) service data units (SDUs) 
on a connection that is provided a particular Quality of Service (QoS). 

3.52 service flow identifier (SFID): A 32-bit quantity that uniquely identifies a service flow to both the 
subscriber station and base station (BS). 

3.53 SS Rx/Tx gap (SSRTG): The SSRTG is the minimum receive to transmit turnaround gap. SSRTG is 
measured from the time of the last sample of the received burst to the first sample of the transmitted burst, at 
the antenna port of the SS. 

3.54 SS Tx/Rx gap (SSTTG): The SSTTG is the minimum transmit to receive turnaround gap. SSTTG is 
measured from the time of the last sample of the transmitted burst to the first sample of the received burst, at 
the antenna port of the SS. 
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3.55 subcarrier index: An index number identifying a particular used subcarrier in an orthogonal frequency 
division multiplexing (OFDM) or orthogonal frequency division multiple access (OFDMA) signal 
Subcarrier indices are greater than or equal to zero. 

3.56 subscriber station (SS): A generalized equipment set providing connectivity between subscriber 
equipment and a base station (BS). 

3.57 time division duplex (TDD): A duplex scheme where uplink and downlink transmissions occur at 
different times but may share the same frequency. 

3.58 time division multiple access (TDMA) burst: A contiguous portion of the uplink or downlink using 
PHY parameters, determined by the Downlink Interval Usage Code (DIUC) or Uplink Interval Usage Code 
(UIUC), that remain constant for the duration of the burst. TDMA bursts are separated by preambles and are 
separated by gaps in transmission if subsequent bursts are from different transmitters. 

3.59 time division multiplexing (TDM) burst: A contiguous portion of a TDM data stream using PHY 
parameters, determined by the Downlink Interval Usage Code (DIUC), that remain constant for the duration 
of the burst. TDM bursts are not separated by gaps or preambles. 

3.60 transport connection: A connection used to transport user data. 

3.61 transport connection identifier: A unique identifier taken from the CID address space that uniquely 
identifies the transport connection. 

3.62 turbo decoding: Iterative decoding, using soft inputs and soft outputs. 

3.63 transmit/receive transition gap (TTG): A gap between the downlink burst and the subsequent uplink 
burst in a time division duplex (TDD) transceiver. This gap allows time for the base station (BS) to switch 
from transmit to receive mode and SSs to switch from receive to transmit mode. During this gap, the BS and 
SS are not transmitting modulated data but simply allowing the BS transmitter carrier to ramp down, the 
transmit/receive (Tx/Rx) antenna switch to actuate, and the BS receiver section to activate. Not applicable 
for FDD systems. 

3.64 type/length/value (TLV): A formatting scheme that adds a tag to each transmitted parameter 
containing the parameter type (and implicitly its encoding rules) and the length of the encoded parameter. 

3.65 uplink: The direction from a subscriber station to the base station (BS). 

3.66 uplink channel descriptor (UCD): A medium access control message that describes the PHY 
characteristics of an uplink. 

3.67 uplink interval usage code (UIUC): An interval usage code specific to an uplink. 

3.68 uplink map (UL-MAP): A set of information that defines the entire access for a scheduling interval. 

3.69 user data: PDUs of any protocol above a Service Specific Convergence Sublayer received over the CS 
SAP. 

3.70 wireless access: End-user radio connection(s) to core networks. 
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4. Abbreviations and acronyms 



3-DES 


triple data encryption standard 


AAS 


adaptive antenna system 


AGC 


automatic gain control 


AK 


authorization key 


ARQ 


automatic repeat request 


ATDD 


adaptive time division duplexing 


ATM 


asynchronous transfer mode 


BCC 


block convolutional code 


BE 


best effort 


BER 


bit error rate 


BPSK 


binary phase shift keying 


BR 


bandwidth request 


BS 


base station 


BSN 


block sequence number 


BTC 


block turbo code 


BW 


bandwidth 


BWA 


broadband wireless access 


/-~\ rr 

C/I 


carrier-to-interference ratio 


C/N 


carrier-to-noise ratio 


CA 


certification authority 


CBC 


cipher block chaining 


CC 


confirmation code 


CCI 


co-channel interference 


CCS 


common channel signaling 


ccv 


clock comparison value 


CDMA 


code division multiple access 


CEPT 


european conference of postal and telecommunications administrations 


CnID 


channel identifier 


CID 


connection identifier 


CINR 


carrier-to-interference-and-noise ratio 


CIR 


channel impulse response 


CLP 


cell loss priority 


CP 


cyclic prefix 


CPS 


common part sublayer 


CRC 


cyclic redundancy check 


CS 


convergence sublayer 


CSCF 


centralized scheduling configuration 


CSCH 


centralized scheduling 


DAMA 


demand assigned multiple access 


DARS 


digital audio radio satellite 


DCD 


downlink channel descriptor 


DES 


data encryption standard 


DFS 


dynamic frequency selection 


DHCP 


dynamic host configuration protocol 


DIUC 


downlink interval usage code 


DL 


downlink 


DM 


directed mesh 


DSA 


dynamic service addition 


DSC 


dynamic service change 


DSCH 


distributed scheduling 


DSCP 


differentiated services codepoint 


DSD 


dynamic service deletion 
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DoX 


aynaimc service duuiiiun, Liiaiige, ui ucicuun 


I1C 


encryption coiiuoi 


bCB 


electronic code book 


bDb 


encrypt-decrypt-encrypt 


EESS 


earth exploratory satellite system 




enecuve isotropic rduidieu power 


EKS 


encryption key sequence 


EVM 


error vector magnitude 


rt 


fragmentation control 


rCri 


frame control header 


ruD 


irequency ui vis ion uupiex or aupiexmg 


FEC 


forward error correction 


FFT 


fast fourier transform 


rrL 


iasi power control 


T7CTJ 

ron 


iragmeniauon suoneauer 


T7CXT 


fragment sequence number 


FSS 


fixed satellite service 


GF 


galois field 


one 

GPS 


global positioning system 


GS 


guard symbol 


HCS 


header check sequence 


Tier' 
HbC 


header error check 


H-FDD 


half-duplex frequency division duplex 


HMAC 


hashed message authentication code 


T IT 

HT 


header type 


TTT TA/f A XT 


nign-speeo uniicenseu meiropoman area neiworK 


I 


inphase 


T A XT A 

1AJNA 


internet assigned numbers authority 


lb 


lniormation eiemeni 


IFFT 


inverse fast fourier transform 


IP 


internet protocol 


TTT T 

ITU 


international telecommunications union 


IWF 


interworking function 


KbK 


key encryption key 


LAN 


local area network 


T "CCD 


linear feedback shift register 


Tip 

LLC 


logical link control 


T AC 

LOS 


line-of-sight 


T CD 

LSr> 


least significant bit 


MAC 


medium access control layer 


If A XT 

MAM 


metropolitan area network 


Mb a 


megabaud 


MBd/s 


megabaud per second 


MD/S 


megabit per second 


MDS 


multipoint distribution service 


MIB 


management information base 


MIC 


message integrity check 


MMDS 


multichannel multipoint distribution service 


MrcAj 


moving pictures experts group 


MSB 


most significant bit 


MSH 


mesh 


NCFG 


network configuration 


NENT 


network entry 


NLOS 


non-line-of-sight 
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NNI 


npfwnrV-to-nptwnrk' intprfapp fnr npfw/nrV noHp intPffar'P^ 

UVsl W \Jl rv IV UblWUlIV HllAvlldlye vvJl IldWvrlA. UUVJe UlLClldCCJ 


nrtPS 


nnn-rpal-ti mp nnllincr cprvir*p 

HVJIl ICdl L1111C pUUUlg aci V1UC 


OFDM 


orthop'onfll frpnnpnrv Hivwinn miiltinlpYinc 


OFDMA 


orthogonal frpfiupnrv Hivisinn mnltinlp apppQQ 


OID 


ohieet ideniiftpr 


PBR 


nipffvhark rpnnpst 


PDU 


nrotocol Hata unit 


PHS 


oavloari hpaHpr siinnrp^Qinn 


PHSF 


oavload hparlpr sunnrp^Qinn fiplH 


PHSI 


nJlvlnaH hpJiHpr Qimnrpccinn inHpY 
pajr luau utauti auppitoMUii inueA 


PHSM 

X X XOIVI 


pavlUoU UCdUCI MipprCSSlOn IlldSlV 


PHSS 


navlnaH npjinpr ciinnrpccinn citp 


PHSV 


navlnnH hpjiHpr Qiinnrpccinn vjjIiH 
payivjavi iicauci ouppicoMUii vaiiu 


PHY 


nhvQiPnl Invpr 

piiYolvdl lajrCl 


PKM 


nriuflfv k"pv ix\a opmpnt 
piivovj v management 


PM 


r\nll_mp Kit 


PMD 

X 1V1.L/ 


pnyMedi iiicuiuni uepenueni 


PMP 


noint-tn-mnltinnint 


PPP 


Ofiint-tfi-rininf nrntnrnl 


PRBS 

X IMIJ 


pbcuuu-idiiuum uuidry deijuenee 


PS 


nHvcipnl dnt 

piiyoll/dl MUl 


PSH 


^avAJIlg oUUilCdUCl 


PTT 

XXX 


pdyiudu iypc liiuicdiur 


PtP 


nninr tn nninf 

LsUllll WJ LJVJllll 


PVC 


nprmiinpnt virtual pirpiiit 

JJeilllalieill VlllUdl C11CU11 


n 

V 


quaaraiure 


QAM 


niif*HrJitiiT*P nmrtlitnHp mnHnlatinn 
IJUdUldlUie dllipilLLlUC lllUUlildllUll 




quality or Service 


QPSK 


nimrlrjitiirp nhncp-.chi'ft Vputnir 
LJUaUlalUlC JJIldoe-MIl 1 1 JvCVIIIt 


REQ 




RLAN 


IdUlU luedl aCCCSS iiciworK 


JVl>vJ 


ranging 


RS 


IvCCiX — OUIUllIUIl 


Ivor 


response 


RSS 


rpppivp ^icnjil Qtrpnoth 


RSSI 


tpppivp ciorml ctrptiotVi inHi^ot/^r 

ICLCl VC Ol^lldl oUCllgtll lllLllL/dlUI 


RTG 


rpppivp/francmit truncitirm ctq r\ 

IttCl V C/ U UllMIIll UdlldlLlUIi fedp 


rixo 


real-time polling service 


Rx 


rpfpivpr 
iecei vci 




icceivcr ueiay spreau clearing lniervai 


SA 


cppnritv Qccr\r»iiitir4n 
accuiiiy dooucidiiuii 


OrxlLJ 


securiiy associauon laeniiiier 


*s AP 

o/\x 


service access point 


O.T\I\ 


synineuc apenure raoar 




single Ldiricr 


0\_ XXj 


society of cable teleconvniunications engineers 


SDU 


Qprvipp Hatfi unit 
oci v itc uala unit 


SF 

ox 


service now 


CT7TP\ 

orlJJ 


service flow identifier 


SHA 


secure hash algorithm 


si 


slip indicator 


SNMP 


simple network management protocol 


SNR 


signal-to-noise ratio 


SS 


subscriber station 
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subscriber station transition gap 


OTP 


space time coding 


oVL 


switched virtual circuit 




transmission convergence sublayer 




trellis coded modulation 




transmission control protocol 




time division duplex or duplexing 


I Dm 


time division multiplexing 


TDMA 


time division multiple access 




traffic encryption key 


Irlr 


trivial file transfer protocol 


1LV 


type/length/value 


1 LKJ 


transmit/receive transition gap 


t v 
IX 


transmitter 


UCD 


uplink channel descriptor 


UDP 


user datagram protocol 


UGS 


unsolicited grant service 


T TTT TO 


uplink interval usage code 


UL 


uplink 


T TXTT 

UNI 


user-to-network interface or user-network interface 


T T XTTT 

U-NII 


unlicensed national information infrastructure 


T FTP 

U 1C 


universal coordinated time 


uw 


unique word 


vc 


virtual channel 


WOT 


virtual channel identifier 


VLAN 


virtual local area network 


VP 


virtual path 


VPI 


virtual path identifier 


WirelessMAN 


Wireless Metropolitan Area Networks 


WirelessHUMAN 


Wireless High-speed Unlicensed Metropolitan Area 


XOR 


exclusive-or 
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5. Service-specific CS 

The service-specific CS resides on top of the MAC CPS and utilizes, via the MAC SAP, the services 
provided by the MAC CPS (see Figure 1). The CS performs the following functions: 

— Accepting higher-layer protocol data units (PDUs) from the higher layer 

— Performing classification of higher-layer PDUs 

— Processing (if required) the higher-layer PDUs based on the classification 

— Delivering CS PDUs to the appropriate MAC SAP 

— Receiving CS PDUs from the peer entity 

Currently, two CS specifications are provided: the asynchronous transfer mode (ATM) CS and the packet 
CS. Other CSs may be specified in the future. 

5.1 ATM CS 

The ATM CS is a logical interface that associates different ATM services with the MAC CPS SAP. The ATM 
CS accepts ATM cells from the ATM layer, performs classification and, if provisioned, PHS y and delivers 
CS PDUs to the appropriate MAC SAP. 

5.1.1 CS service definition 

The ATM CS is specifically defined to support the convergence of PDUs generated by the ATM layer 
protocol of an ATM network. Since ATM cell streams are generated according to the ATM standards, no 
ATM CS service primitive is required. 

5.1.2 Data/Control plane 
5.1.2.1 PDU formats 

The ATM CS PDU shall consist of an ATM CS PDU Header, defined in Table 2, and the ATM CS PDU 
payload. The ATM CS PDU payload shall be equal to the ATM cell payload. The ATM CS PDU is 
illustrated in Figure 3. 



Table 2— ATM CS PDU header 



Syntax 


Size 


Notes 


ATM_CS_PDU_Header 0 { 






if (no PHS) { 






ATM_Header 


40 bits 


The full ATM cell header j 


} 






else if (VP-switched) { 






PTI 


3 bits 


From the ATM cell header 


CLP 


1 bit 


From the ATM cell header 


reserved 


4 bits 


Shall be set to zero 


VCI 


16 bits 


From the ATM cell header 


I } 






else (VC-switched) { 






PTI 


3 bits 


From the ATM cell header 
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Tab le 2— ATM CS PDU header (continued) 



Syntax 


Size 


Notes 


CLP 


1 bit 


From the ATM cell header 


reserved 


4 bits 


Shall be set to zero 


J ) 






} 







ATM CS PDU 
Header 



ATM CS PDU Payload (48 bytes) 



Figure 3— ATM CS PDU format 



5.1.2.2 Classification 



An ATM connection, which is uniquely identified by a pair of values of virtual path identifier (VPI) and 
virtual channel identifier (VCI), is either Virtual Path (VP) switched or Virtual Channel (VC) switched. In 
VP-switched mode, all VCIs within one single incoming VPI are automatically mapped to that of an 
outgoing VPI. In VC-switched mode, input VPI/VCI values are individually mapped to output VPI/VCI 
values. Thus, when performing PHS, the ATM CS differentiates these two types of connections and 
performs the suppression accordingly. 

A classifier is a set of matching criteria applied to each ATM cell entering the ATM CS. It consists of some 
ATM cell matching criteria, such as VPI and VCI, and a reference to a CID. If an ATM cell matches the 
specified matching criteria, it is delivered to the MAC SAP for delivery on the connection identified by the 
CID. 

5.1.2.2.1 VP-switched mode 

For VP-switched mode, the VPI field, 12 bits for a network-to-network interface (NNI) and 8 bits for a 
user-to-network interface (UNI), is mapped to the 16-bit CID for the MAC connection on which it is 
transported. Since the QoS and category of service parameters for the connection are set at connection 
establishment, this mapping of VPI to CID guarantees the correct handling of the traffic by the MAC. 

5.1 .2.2.2 VC-switched mode 

For VC-switched mode, the VPI and VCI fields, 28 bits total for an NNI and 24 bits total for a UNI, are 
mapped to the 16-bit CID for the MAC connection on which it is transported. Since the QoS and category of 
service parameters for the connection are set at connection establishment, this mapping of VPI and VCI to 
CID guarantees the correct handling of the traffic by the MAC. Note that the full range of VPI/VCI 
combinations (up to 2 28 for NNI and 2 24 for UNI) cannot be simultaneously supported in this mode. 

5.1.2.3 PHS 

In PHS, a repetitive portion of the payload headers of the CS SDUs is suppressed by the sending entity and 
restored by the receiving entity. On the downlink, the sending entity is the ATM CS on the BS and the 
receiving entity is the ATM CS on the SS. On the uplink, the sending entity is the ATM CS on the SS, and 
the receiving entity is the ATM CS on the BS. To further save bandwidth, multiple ATM cells (with or 
without PHS) that share the same CID may be packed and carried by a single MAC CPS PDU. Note that 
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when PHS is turned off, no part of any ATM cell header including Header Error Check (HEC) field shall be 
suppressed. This provides an option for protecting the integrity of the cell header. Whether or not PHS is 
applied to an ATM connection is signaled in the Dynamic Service Addition (DSA) Request (DSA-REQ) 
message at the connection's creation. Similarly, the VPI (for VP-switched connections) or the VPI/VCI (for 
VC-s witched connections) is also signaled in the classifier settings of the DSA-REQ message at connection 
creation. 

5.1.2.3.1 PHS for VP-switched ATM connections 

In VP-switched mode, the VPI is mapped to a CID. This allows the disposal of the remainder of the ATM 
cell header except for the VCI, Payload Type Indicator (PTI), and Cell Loss Priority (CLP) fields. These 
fields shall be encapsulated in the CS PDU header. 

Figure 4 shows a CS PDU containing a single VP-switched ATM cell with the cell header suppressed and 
the format of the ATM CS PDU Header for VP-switched ATM connections. 



ATM CS 
Header 



ATM Cell Payload (48 bytes) 




PTI 


CLP 


reserved 


VCI 


(3 bits) 


(1 bit) 


(4 bits) 


(16 bits) 



Figure 4— CS PDU format for VP-switched ATM connections 



5.1 .2.3.2 PHS for VC-switched ATM connections 

In VC-switched mode, the VPI/VCI combination is mapped to a CID. This allows the disposal of the 
remainder of the ATM cell header except for the PTI and CLP fields. These fields shall be encapsulated in 
the CS PDU Header. 

Figure 5 shows a CS PDU containing a single VC-switched ATM cell with the cell header suppressed and 
the format of the ATM CS PDU header for VC-switched ATM connections. 



ATM CS 
Header 



ATM Cell Payload (48 bytes) 



PTI 


CLP 


reserved 


(3 bits) 


(1 bit) 


(4 bits) 



Figure 5— CS PDU format for VC-switched ATM connections 



5.1.2.4 Signaling procedure 

ATM interfaces support three types of connections, switched virtual circuit (SVC), permanent virtual circuit 
(PVC), and soft PVC. SVCs are established and terminated dynamically on demand by the use of signaling. 
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The word "permanent" signifies that the circuit is established administratively. Although both PVC and soft 
PVC are established administratively, PVCs are established by provisioning process, and soft PVCs are 
established by the use of signaling. 

ATM networks use common channel signaling (CCS), where signaling messages are carried over a 
connection completely independent of user connections and where one signaling channel can carry signaling 
messages for a number of user connections. Per nonassociated signaling (ATM as- sig-006 1.000), by default, 
the signaling channel on VPI = 0 controls all VPs on the same physical interface. In other words, except 
when the optional proxy signaling capability (Annex 2 of ATM as-sig-0061.000) or when the optional 
Virtual UNI capability (Annex 8 of ATM as-sig-0061.000) is used, the signaling channel is identified by 
VPI = 0 and VCI = 5. Note that this specification does not support associated signaling (ATM af-uni- 
0010.002), where VCI = 5 of each VP is used as the signaling channel for all VCs on the same VP. In 
addition, this specification does not support either proxy signaling or virtual UNI. 

To establish an SVC, it is the responsibility of the calling party to initiate the signaling procedure by issuing 
the appropriate signaling messages. Either end can establish or release the SVC. Details on how to use these 
signaling messages are available in ATM as-sig-0061.000. It shall be the responsibility of the 
implementation of the BS to map ATM signaling messages to corresponding MAC CPS service primitives. 

To establish a soft PVC, the network management system provisions one end of the soft PVC with the 
address identifying the egress ATM interface of the ATM network. The calling end has the responsibility for 
establishing and releasing the connection. It is also the responsibility of the calling party (if necessary) to 
reestablish the connection in case of switching system or link failure. It shall be the responsibility of the 
implementation of the BS to map ATM signaling messages to corresponding MAC CPS service primitives. 

On the downlink direction, the signaling starts at an "end user" of the ATM backhaul network that 
implements an ATM UNI and terminates at the BS that shall implement either an ATM UNI or an ATM 
NNI. The signaling may be mapped by an interworking function (IWF) and extended to some user network 
on the SS-side. On the uplink direction, the signaling starts at the ATM interface of the BS and ends at the 
ATM UNI of an "end user." In addition, the signaling may be originated by an "end user" of some user 
network and mapped by the IWF. Note that mapping of data units carried by the air link shall be limited to 
only cell-level convergence (5.1.2.2). If required by a user network, other levels of mappings (e.g., the 
convergence of, say, an Ethernet packet to ATM cells) shall be handled by the user network's IWF 
exclusively. 

During the provisioning process, each SS joining the IEEE Std 802.16 system shall request a dedicated CID 
as the signaling connection corresponding to the CCS connection used by ATM networks. Any CID 
provisioned for this purpose shall not be dynamically changed or terminated. Each IEEE Std 802.16 system 
shall provision a set of CIDs for this purpose. 

5.2 Packet CS 

The packet CS resides on top of the IEEE Std 802.16 MAC CPS. The CS performs the following functions, 
utilizing the services of the MAC: 

a) Classification of the higher-layer protocol PDU into the appropriate connection 

b) Suppression of payload header information (optional) 

c) Delivery of the resulting CS PDU to the MAC SAP associated with the service flow for transport to 
the peer MAC SAP 

d) Receipt of the CS PDU from the peer MAC SAP 

e) Rebuilding of any suppressed payload header information (optional) 
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The sending CS is responsible for delivering the MAC SDU to the MAC SAP. The MAC is responsible for 
delivery of the MAC SDU to peer MAC SAP in accordance with the QoS, fragmentation, concatenation, 
and other transport functions associated with a particular connection's service flow characteristics. The 
receiving CS is responsible for accepting the MAC SDU from the peer MAC SAP and delivering it to a 
higher-layer entity. 

The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), 
Point-to-Point Protocol (PPP), and IEEE Std 802.3 (Ethernet). 

5.2.1 MAC SDU format 

Once classified and associated with a specific MAC connection, higher-layer PDUs shall be encapsulated in 
the MAC SDU format as illustrated in Figure 6. The 8-bit Payload Header Suppression Index (PHSI) field 
shall be present when a Payload Header Suppression (PHS) rule has been defined for the associated 
connection. 



Payload Header Suppression is described in 5.2.3. 



—//- 

MAC SDU 

—/A — 



PHSI 
(optional) 



Packet PDU 



Figure 6— MAC SDU format 



5.2.2 Classification 

Classification is the process by which a MAC SDU is mapped onto a particular connection for transmission 
between MAC peers. The mapping process associates a MAC SDU with a connection, which also creates an 
association with the service flow characteristics of that connection. This process facilitates the delivery of 
MAC SDUs with the appropriate QoS constraints. 

A classifier is a set of matching criteria applied to each packet entering the IEEE Std 802.16 network. It 
consists of some protocol -specific packet matching criteria (destination IP address, for example), a classifier 
priority, and a reference to a CID. If a packet matches the specified packet matching criteria, it is then 
delivered to the SAP for delivery on the connection defined by the CID. Implementation of each specific 
classification capability (as, for example, IPv4 based classification) is optional. The service flow 
characteristics of the connection provide the QoS for that packet. 

Several classifiers may each refer to the same service flow. The classifier priority is used for ordering the 
application of classifiers to packets. Explicit ordering is necessary because the patterns used by classifiers 
may overlap. The priority need not be unique, but care shall be taken within a classifier priority to prevent 
ambiguity in classification. Downlink classifiers are applied by the BS to packets it is transmitting and 
uplink classifiers are applied at the SS. Figure 7 and Figure 8 illustrate the mappings discussed in the 
previous paragraph. 
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It is possible for a packet to fail to match the set of defined classifiers. In this case, the CS shall discard the 
packet. 




{SDU, CID, „,} 
<i SAP > 



802.16 MAC CPS 



Upper Layer Entity (e.g., bridge, router, host) 



A 
-A 



< 



SDU 



SAP > - 



Reconstitution 
(e.g., undo PHS) 



{SDU, CID, „,} 



< SAP > 



SS 



802.16 MAC CPS 



Figure 7— Classification and CID mapping (BS to SS) 



Upper Layer Entity (e.g., bridge, router) 



SDU 



< SAP 



Reconstitution 
(e.g., undo PHS) 



{SDU, CID, ,„} 



<Isapl> 



BS 



802.16 MAC CPS 



A 

Kr 



SDU 



SAP > 



Uplink 
Classifier 



CID1 



CID 2 



CIDn 



{SDU, CID, ,„} 
- < SAP > - 



SS 



802.16 MAC CPS 



Figure 8 — Classification and CID mapping (SS to BS) 
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5.2.3 PHS 

In PHS, a repetitive portion of the payload headers of the higher layer is suppressed in the MAC SDU by the 
sending entity and restored by the receiving entity. Implementation of PHS capability is optional. On the 
uplink, the sending entity is the SS and the receiving entity is the BS. On the downlink, the sending entity is 
the BS and the receiving entity is the SS. If PHS is enabled at MAC connection, each MAC SDU is prefixed 
with a PHSI, which references the Payload Header Suppression Field (PHSF). 

The sending entity uses classifiers to map packets into a service flow. The classifier uniquely maps packets 
to its associated PHS Rule. The receiving entity uses the CID and the PHSI to restore the PHSF. Once a 
PHSF has been assigned to a PHSI, it shall not be changed. To change the value of a PHSF on a service flow, 
a new PHS rule shall be defined, the old rule is removed from the service flow, and the new rule is added. 
When a classifier is deleted, any associated PHS rule shall also be deleted. 

PHS has a Payload Header Suppression Valid (PHSV) option to verify or not verify the payload header 
before suppressing it. PHS has also a Payload Header Suppression Mask (PHSM) option to allow select 
bytes not to be suppressed. The PHSM facilitates suppression of header fields that remain static within a 
higher-layer session (e.g. IP addresses), while enabling transmission of fields that change from packet to 
packet (e.g. IP Total Length). 

The BS shall assign all PHSI values just as it assigns all CID values. Either the sending or the receiving 
entity shall specify the PHSF and the Payload Header Suppression Size (PHSS). This provision allows for 
preconfigured headers or for higher level signaling protocols outside the scope of this standard to establish 
cache entries. 

It is the responsibility of the higher-layer service entity to generate a PHS Rule that uniquely identifies the 
suppressed header within the service flow. It is also the responsibility of the higher-layer service entity to 
guarantee that the byte strings that are being suppressed are constant from packet to packet for the duration 
of the active service flow. 

5.2.3.1 PHS operation 

SS and BS implementations are free to implement PHS in any manner as long as the protocol specified in 
this subclause is followed. Figure 9 illustrates the following procedure. 

A packet is submitted to the packet CS. The SS applies its list of Classifier rules. A match of the rule shall 
result in an Uplink Service Flow, CID, and a PHS Rule. The PHS Rule provides PHSF, PHSI, PHSM, PHSS, 
and PHSV. If PHSV is set or not present, the SS shall compare the bytes in the packet header with the bytes 
in the PHSF that are to be suppressed as indicated by the PHSM. If they match, the SS shall suppress all the 
bytes in the Uplink PHSF except the bytes masked by PHSM. The SS shall then prefix the PDU with the 
PHSI and present the entire MAC SDU to the MAC SAP for transport on the uplink. 

When the MAC PDU is received by the BS from the air interface, the BS MAC layer shall determine the 
associated CID by examination of the generic MAC header. The BS MAC layer sends the PDU to the MAC 
SAP associated with that CID. The receiving packet CS uses the CID and the PHSI to look up PHSF, PHSM, 
and PHSS. The BS reassembles the packet and then proceeds with normal packet processing. The 
reassembled packet contains bytes from the PHSF If verification was enabled, then the PHSF bytes equal 
the original header bytes. If verification was not enabled, then there is no guarantee that the PHSF bytes 
match the original header bytes. 

A similar operation occurs on the downlink. The BS applies its list of Classifiers. A match of the Classifier 
shall result in a Downlink Service Flow and a PHS Rule. The PHS Rule provides PHSF, PHSI, PHSM, 
PHSS, and PHSV If PHSV is set or not present, the BS shall verify the Downlink Suppression Field in the 
packet with the PHSF. If they match, the BS shall suppress all the bytes in the Downlink Suppression Field 
except the bytes masked by PHSM. The BS shall then prefix the PDU with the PHSI and present the entire 
MAC SDU to the MAC SAP for transport on the downlink. 
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The SS shall receive the packet based upon the CID Address filtering within the MAC. The SS receives the 
PDU and then sends it to the CS. The CS then uses the PHSI and CID to lookup PHSF, PHSM, and PHSS. 
The SS reassembles the packet and then proceeds with normal packet processing. 

Figure 10 demonstrates packet suppression and restoration when using PHS masking. Masking allows only 
bytes that do not change to be suppressed. Note that the PHSF and PHSS span the entire suppression field, 
included suppressed and unsuppressed bytes. 
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Packet to 
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r END ^ 



Figure 9— PHS operation 
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Figure 10 — PHS with masking 



5.2.3.2 PHS signaling 

PHS requires the creation of the following three objects: 

a) Service flow 

b) Classifier 

c) PHS rule 

These three objects may be created either simultaneously or in separate message flows. 

PHS Rules are created with DSA or Dynamic Service Change (DSC) messages. The BS shall define the 
PHSI when the PHS Rule is created. PHS rules are deleted with the DSC or Dynamic Service Deletion 
(DSD) messages. The SS or BS may define the PHSS and PHSF. To change the value of a PHSF on a service 
flow, a new PHS rule shall be defined, the old rule is removed from the service flow, and the new rule is 
added. 

Figure 11 shows the two ways to signal the creation of a PHS rule. 

It is possible to partially specify a PHS rule (in particular the size of the rule) at the time a service flow is 
created. As an example, it is likely that when a service flow is first provisioned, the header fields to be 
suppressed will be known. The values of some of the fields [for example: IP addresses, User Datagram 
Protocol (UDP) port numbers, etc.] may be unknown and would be provided in a subsequent DSC as part of 
the activation of the service flow (using the "Set PHS Rule" DSC Action). If the PHS rule is being defined in 
more than one step, each step, whether it is a DSA or DSC message, shall contain both the SFID (or 
reference) and a PHS index to uniquely identify the PHS rule that is being defined. 



26 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



BS-Initiated 


SS-Initiated 


BS SS 


BS SS 


DSC-REQ 


Classifier Reference 
+ PHSI + PHSS + PHSF ^ 




Classifier Reference 
^ + PHSS + PHSF 


DSC-REQ 


DSC-RSP 


4 




PHSI 


DSC-RSP 


DSC-ACK 






► 


DSC-ACK 




► 




4 





Figure 11— PHS signaling example 



5.2.4 IEEE Std 802.3/Ethernet-specific part 
5.2.4.1 IEEE Std 802.3/Ethernet CS PDU format 

The IEEE Std 802.3/Ethernet PDUs are mapped to MAC SDUs according to Figure 12 (when header 
suppression is enabled at the connection, but not applied to the CS PDU) or Figure 13 (with header 
suppression). 





PHSI=0 


IEEE 802.3/Ethernet PDU 




Figure 12— IEEE 802.3/Ethernet CS PDU format without header suppression 




PHSM) 


Header-Suppressed 
IEEE 802.3/Ethernet PDU 





Figure 13— IEEE 802.3/Ethernet CS PDU format with header suppression 



5.2.4.2 IEEE Std 802.3/Ethernet CS classifiers 



The following parameters are relevant for IEEE Std 802.3/Ethernet CS classifiers: 

Logical link control (LLC) classification parameters — zero or more of the LLC classification parameters 
(destination MAC address, source MAC address, Ethertype/SAP). 

For IP over IEEE 802.3/Ethernet, IP headers may be included in classification. In this case, the IP 
classification parameters (11.13.19.3.4.2-11.13.19.3.4.7) are allowed. 
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5.2.5 IEEE Std 802.1 Q-1 998 virtual local area network (VLAN) specific part 



This CS shall be employed when IEEE Std 802.1 Q-1 998 tagged VLAN frames are to be carried over the 
IEEE Std 802. 16 network. 

5.2.5.1 IEEE Std 802.1 Q-1 998 VLAN CS PDU format 

The format of the IEEE Std 802.1Q-1998 VLAN CS PDU shall be as shown in Figure 14 (when header 
suppression is enabled at the connection, but not applied to the CS PDU) or Figure 15 (with header 
suppression). 



PHSI=0 



IEEE802.1Q VLAN tagged frame 



Figure 14— IEEE 802.1 Q VLAN CS PDU format without header suppression 



PHSW) 



Header-Suppressed 
IEEE802.1Q VLAN tagged frame 



Figure 15— IEEE 802.1 Q VLAN CS PDU format with header suppression 



5.2.5.2 IEEE Std 802.1 Q-1 998 CS classifiers 

The following parameters are relevant for IEEE Std 802.1Q-1998 CS classifiers: 

LC classification parameters — zero or more of the LLC classification parameters (Destination MAC 
address, source MAC address, Ethertype/SAP). 

IEEE Std 802. ID- 1998 Parameters— zero or more of the IEEE classification parameters 
(IEEE Std 802.1D-1998 Priority Range, IEEE Std 802.1Q-1998 VLAN ID). 

For IP over IEEE Std 802.1 Q-1 998 VLAN, IP headers may be included in classification. In this case, the IP 
classification parameters (11.13.19.3.4.2—11.13.19.3.4.7) are allowed. 

5.2.6 IP specific part 

This subclause applies when IP (IETF RFC 791, IETF RFC 2460) is carried over the 
IEEE Std 802.16 network. 

5.2.6.1 IP CS PDU format 

The format of the IP CS PDU shall be as shown in Figure 16 (when header suppression is enabled at the 
connection, but not applied to the CS PDU) or Figure 17 (with header suppression). 
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PHSI=0 


IP Packet (including header) 


Figure 16— IP CS PDU format without header suppression 


PHSI*0 


Header-Suppressed IP Packet 



Figure 17— IP CS PDU format with header suppression 
5.2.6.2 IP classifiers 

IP classifiers operate on the fields of the IP header and the transport protocol. The parameters 
(11.13.19.3.4.2-11.13.19.3.4.7) may be used in IP classifiers. 
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6. MAC common part sublayer 

A network that utilizes a shared medium shall provide an efficient sharing mechanism. Two-way PMP and 
Mesh topology wireless networks are examples for sharing wireless- media. Here, the medium is the space 
through which the radio waves propagate. 

Though the MAC specification invokes IP protocols, they are required only as a standard basis for element 
management rather than MAC operation, since, in all practicality, element management is necessary in this 
type of network. 

6.1 PMP 

The downlink, from the BS to the user, operates on a PMP basis. The IEEE Std 802.16 wireless link operates 
with a central BS and a sectorized antenna that is capable of handling multiple independent sectors 
simultaneously. Within a given frequency channel and antenna sector, all stations receive the same 
transmission, or parts thereof. The BS is the only transmitter operating in this direction, so it transmits 
without having to coordinate with other stations, except for the overall time division duplexing (TDD) that 
may divide time into uplink and downlink transmission periods. The downlink is generally broadcast. In 
cases where the DL-MAP does not explicitly indicate that a portion of the downlink subframe is for a 
specific SS, all SSs capable of listening to that portion of the downlink subframe shall listen. The SSs check 
the CIDs in the received PDUs and retain only those PDUs addressed to them. 

Subscriber stations share the uplink to the BS on a demand basis. Depending on the class of service utilized, 
the SS may be issued continuing rights to transmit, or the right to transmit may be granted by the BS after 
receipt of a request from the user. 

In addition to individually addressed messages, messages may also be sent on multicast connections (control 
messages and video distribution are examples of multicast applications) as well as broadcast to all stations. 

Within each sector, users adhere to a transmission protocol that controls contention between users and 
enables the service to be tailored to the delay and bandwidth requirements of each user application. This is 
accomplished through four different types of uplink scheduling mechanisms. These are implemented using 
unsolicited bandwidth grants, polling, and contention procedures. Mechanisms are defined in the protocol to 
allow vendors to optimize system performance by using different combinations of these bandwidth 
allocation techniques while maintaining consistent interoperability definitions. For example, contention may 
be used to avoid the individual polling of SSs that have been inactive for a long period of time. 

The use of polling simplifies the access operation and guarantees that applications receive service on a 
deterministic basis if it is required. In general, data applications are delay tolerant, but real-time applications 
like voice and video require service on a more uniform basis and sometimes on a very tightly-controlled 
schedule. 

The MAC is connection-oriented. For the purposes of mapping to services on SSs and associating varying 
levels of QoS, all data communications are in the context of a connection. Service flows may be provisioned 
when an SS is installed in the system. Shortly after SS registration, connections are associated with these 
service flows (one connection per service flow) to provide a reference against which to request bandwidth. 
Additionally, new connections may be established when a customer's service needs change. A connection 
defines both the mapping between peer convergence processes that utilize the MAC and a service flow. The 
service flow defines the QoS parameters for the PDUs that are exchanged on the connection. 

The concept of a service flow on a connection is central to the operation of the MAC protocol. Service flows 
provide a mechanism for uplink and downlink QoS management. In particular, they are integral to the 
bandwidth allocation process. An SS requests uplink bandwidth on a per connection basis (implicitly 
identifying the service flow). Bandwidth is granted by the BS to an SS as an aggregate of grants in response 
to per connection requests from the SS. 
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Connections, once established, may require active maintenance. The maintenance requirements vary 
depending upon the type of service connected. For example, unchannelized Tl services require virtually no 
connection maintenance since they have a constant bandwidth allocated every frame. Channelized Tl 
services require some maintenance due to the dynamic (but relatively slowly changing) bandwidth 
requirements if compressed, coupled with the requirement that full bandwidth be available on demand. IP 
services may require a substantial amount of ongoing maintenance due to their bursty nature and due to the 
high possibility of fragmentation. As with connection establishment, modifiable connections may require 
maintenance due to stimulus from either the SS or the network side of the connection. 

Finally, connections may be terminated. This generally occurs only when a customer's service contract 
changes. The termination of a connection is stimulated by the BS or SS. 

All three of these connection management functions are supported through the use of static configuration 
and dynamic addition, modification, and deletion of connections. 

6.2 Mesh 

The main difference between the PMP and optional Mesh modes is that in the PMP mode, traffic only occurs 
between the BS and SSs, while in the Mesh mode traffic can be routed through other SSs and can occur 
directly between SSs. Depending on the transmission protocol algorithm used, this can be done on the basis 
of equality using distributed scheduling, or on the basis of superiority of the Mesh BS, which effectively 
results in centralized scheduling, or on a combination of both. 

Within a Mesh network, a system that has a direct connection to backhaul services outside the Mesh 
network, is termed a Mesh BS. All the other systems of a Mesh network are termed Mesh SS. In general, the 
systems of a Mesh network are termed nodes. Within Mesh context, uplink and downlink are defined as 
traffic in the direction of the Mesh BS and traffic away from the Mesh BS, respectively. 

The other three important terms of Mesh systems are neighbor, neighborhood and extended neighborhood. 
The stations with which a node has direct links are called neighbors. Neighbors of a node shall form a neigh- 
borhood. A node's neighbors are considered to be "one hop" away from the node. An extended neighbor- 
hood contains, additionally, all the neighbors of the neighborhood. 

In a Mesh system not even the Mesh BS can transmit without having to coordinate with other nodes. Using 
distributed scheduling, all the nodes including the Mesh BS shall coordinate their transmissions in their two- 
hop neighborhood and shall broadcast their schedules (available resources, requests and grants) to all their 
neighbors. Optionally the schedule may also be established by directed uncoordinated requests and grants 
between two nodes. Nodes shall ensure that the resulting transmissions do not cause collisions with the data 
and control traffic scheduled by any other node in the two-hop neighborhood. There is no difference in the 
mechanism used in determining the schedule for downlink and uplink. 

Using centralized scheduling, resources are granted in a more centralized manner. The Mesh BS shall gather 
resource requests from all the Mesh SSs within a certain hop range. It shall determine the amount of granted 
resources for each link in the network both in downlink and uplink, and communicates these grants to all the 
Mesh SSs within the hop range. The grant messages do not contain the actual schedule, but each node shall 
compute it by using the predetermined algorithm with given parameters. 

All the communications are in the context of a link, which is established between two nodes. One link shall 
be used for all the data transmissions between the two nodes. QoS is provisioned over links on a message- 
by-message basis. No service or QoS parameters are associated with a link, but each unicast message has 
service parameters in the header. Traffic classification and flow regulation are performed at the ingress node 
by upper-layer classification/regulation protocol. The service parameters associated with each message shall 
be communicated together with the message content via the MAC SAP. 
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Mesh systems typically use omnidirectional or 360° steerable antennas, but can also be co-located using 
sector antennas. At the edge of the coverage area of the Mesh network, where only a connection to a single 
point is needed, even highly directional antennas can be used. 

6.3 Data/Control plane 

6.3.1 Addressing and connections 

6.3.1.1 PMP 

Each SS shall have a 48-bit universal MAC address, as defined in IEEE Std 802®-2001. This address 
uniquely defines the SS from within the set of all possible vendors and equipment types. It is used during the 
initial ranging process to establish the appropriate connections for an SS. It is also used as part of the 
authentication process by which the BS and SS each verify the identity of the other. 

Connections are identified by a 16-bit CID. At SS initialization, two pairs of management connections 
(uplink and downlink) shall be established between the SS and the BS and a third pair of management 
connections may be optionally generated. The three pairs of connections reflect the fact that there are 
inherently three different levels of QoS for management traffic between an SS and the BS. The basic 
connection is used by the BS MAC and SS MAC to exchange short, time-urgent MAC management 
messages. The primary management connection is used by the BS MAC and SS MAC to exchange longer, 
more delay-tolerant MAC management messages. Table 14 specifies which MAC Management messages 
are transferred on which of these two connections. Finally, the Secondary Management Connection is used 
by the BS and SS to transfer delay tolerant, standards-based [Dynamic Host Configuration Protocol 
(DHCP), Trivial File Transfer Protocol (TFTP), SNMP, etc.] messages. These messages are carried in IP 
datagrams, as specified in 5.2.6. Messages carried on the Secondary Management Connection may be 
packed and/or fragmented. For the SCa, OFDM, and OFDMA PHY layers, management messages shall 
have CRC. Use of the secondary management connection is required only for managed SS. 

The CIDs for these connections shall be assigned in the RNG-RSP and REG-RSP messages. The message 
dialogs provide three CID values. The same CID value is assigned to both members (uplink and downlink) 
of each connection pair. 

For bearer services, the BS initiates the set-up of connections based upon the provisioning information 
distributed to the BS. The registration of an SS, or the modification of the services contracted at an SS, 
stimulates the higher layers of the BS to initiate the setup of the connections. 

The CID can be considered a connection identifier even for nominally connectionless traffic like IP, since it 
serves as a pointer to destination and context information. The use of a 16-bit CID permits a total of 64K 
connections within each downlink and uplink channel. 

Requests for transmission are based on these CIDs, since the allowable bandwidth may differ for different 
connections, even within the same service type. For example, an SS unit serving multiple tenants in an office 
building would make requests on behalf of all of them, though the contractual service limits and other 
connection parameters may be different for each of them. 

Many higher-layer sessions may operate over the same wireless CID. For example, many users within a 
company may be communicating with Transmission Control Protocol (TCP)/IP to different destinations, but 
since they all operate within the same overall service parameters, all of their traffic is pooled for request/ 
grant purposes. Since the original local area network (LAN) source and destination addresses are 
encapsulated in the payload portion of the transmission, there is no problem in identifying different user 
sessions. 
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The type of service and other current parameters of a service are implicit in the CID; they may be accessed 
by a lookup indexed by the CID. 

6.3.1.2 Mesh 

Each node shall have a 48-bit universal MAC address, as defined in IEEE Std 802-2001. The address 
uniquely defines the node from within the set of all possible vendors and equipment types. This address is 
used during the network entry process and as part of the authorization process by which the candidate node 
and the network verify the identity of each other. 

When authorized to the network the candidate node shall receive a 16-bit node identifier (Node ID) upon a 
request to the Mesh BS. Node ID is the basis for identifying nodes during normal operation. The Node ID is 
transferred in the Mesh subheader, which follows the generic MAC header, in both unicast and broadcast 
messages. 

For addressing nodes in the local neighborhood, 8-bit link identifiers (Link IDs) shall be used. Each node 
shall assign an ID for each link it has established to its neighbors. The Link IDs are communicated during 
the Link Establishment process as neighboring nodes establish new links. The Link ID is transmitted as part 
of the CID in the generic MAC header in unicast messages. The Link IDs shall be used in distributed 
scheduling to identify resource requests and grants. Since these messages are broadcast, the receiver nodes 
can determine the schedule using the transmitter's Node ID in the Mesh subheader, and the Link ID in the 
payload of the MSH-DSCH (Mesh Mode Schedule with Distributed Scheduling) message. 

The Connection ID in Mesh mode is specified as shown in Table 3 to convey broadcast/unicast, service 
parameters, and the link identification. 



Table 3 — Mesh CID construction 



Syntax 


Size 


Notes 


CID { 






if (Xmt Link ID = OxFF) { 






Logical Network ID 


8 bits 


0x00: All-net Broadcast 


} else { 






Type 


2 bits 


0x0: MAC Management 
0x1: IP 

0x2-0x3: Reserved 


Reliability 


1 bit 


0x0: No retransmissions 
0x1: Up to 4 retransmissions 


Priority/Class 


3 bits 




Drop Precedence 


2 bits 




; } 






Xmt Link ID 


8 bits 


OxFF: MAC management broadcast 


} 







Priority/Class 

Priority field indicates message class. 
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Drop Precedence 

Messages with larger Drop Precedence shall have higher dropping likelihood during congestion. 
Xmt Link ID 

The Link ID is assigned by the transmitter node to the link to the receiver node. 
6.3.2 MAC PDU formats 



MAC PDUs shall be of the form illustrated in Figure 18. Each PDU shall begin with a fixed-length generic 
MAC header. The header may be followed by the Payload of the MAC PDU. If present, the Payload shall 
consist of zero or more subheaders and zero or more MAC SDUs and/or fragments thereof. The payload 
information may vary in length, so that a MAC PDU may represent a variable number of bytes. This allows 
the MAC to tunnel various higher-layer traffic types without knowledge of the formats or bit patterns of 
those messages. 



CO 
CO 



CD 

CO 



Generic MAC header 



-//- 



Payload (optional) 

Y/> 



CRC (optional) 



Figure 18— MAC PDU formats 



A MAC PDU may contain a CRC, as described in 63.3.5. Implementation of CRC capability is mandatory 
for SCa, OFDM and OFDMA PHY layers. 

6.3.2.1 MAC header formats 

Two MAC header formats are defined. The first is the generic MAC header that begins each MAC PDU 
containing either MAC management messages or CS data. The second is the bandwidth request header used 
to request additional bandwidth. The single-bit Header Type (HT) field distinguishes the generic MAC 
header and bandwidth request header formats. The HT field shall be set to zero for the Generic Header and 
to one for a bandwidth request header. 



The MAC header formats are defined in Table 4. 



Table 4— MAC header format 



Syntax 


Size 


Notes 


MAC HeaderO { 






HT 


Ibit 


0 = Generic MAC header 

1 = Bandwidth request header 


EC 


Ibit 


If HT = 1, EC = 0 


if (HT == 0) { 






Type 


6 bits 




reserved 


Ibit 


Shall be set to zero 


CI 


1 bit 
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Table 4— MAC header format (continued) 



Syntax 


Size 


Notes 


EKS 


2 bits 




reserved 


lbit 


Shall be set to zero 


LEN 


11 bits 




} 






else { 






Type 


3 bits 




BR 


19 bits 




} 






CTD 


16 bits 




HCS 


8 bits 




} 







6.3.2.1.1 Generic MAC header 

The generic MAC header is illustrated in Figure 19. 
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Figure 19 — Generic MAC header format 
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The fields of the generic MAC header are defined in Table 5. Every header is encoded, starting with the HT 
and encryption control (EC) fields. The coding of these fields is such that the first byte of a MAC header 
shall never have the value of OxFX, where "X" means "don't care." This prevents false detection on the stuff 
byte used in the Transmission Convergence sublayer. 



Table 5 — Generic MAC header fields 



Name 


Length 
(bits) 


Description 


CI 


1 


CRC Indicator 

1 = CRC is included in the PDU by appending it to the PDU Payload after encryption, if any 
0 = No CRC is included 


CID 


16 


Connection identifier 


EC 


1 


Encryption Control 

0 = Payload is not encrypted 

1 = Payload is encrypted 


EKS 


2 


Encryption Key Sequence 

The index of the Traffic Encryption Key (TEK) and Initialization Vector used to encrypt the 
payload. This field is only meaningful if the EC field is set to 1 . 


HCS 


8 


Header Check Sequence 

An 8-bit field used to detect errors in the header. The transmitter shall calculate the HCS 
value for the first five bytes of the cell header, and insert the result into the HCS field (the 
last byte of the MAC header). It shall be the remainder of the division (Modulo 2) by the 
generator polynomial g(D = D 8 + D 2 + D + 1 of the polynomial D 8 multiplied by the content 
of the header excluding the HCS field. (Example: [HT EC Type]=0x80, BR=0xAAAA, 
CID=0x0F0F; HCS should then be set to 0xD5). 


HT 


1 


Header Type. Shall be set to zero. 


LEN 


11 . 


Length. The length in bytes of the MAC PDU including the MAC header and the CRC if 
present. 


TVpe 


6 


This field indicates the subheaders and special payload types present in the message payload. 



The definition of the Type field is indicated in Table 6. 



Table 6— Type encodings 



Type bit 


Value 


#5 

most significant bit (MSB) 


Mesh subheader 

1 = present, 0 = absent j 


#4 


ARQ Feedback Payload 
1 = present, 0 = absent 


#3 


Extended Type 

Indicates whether the present Packing or Fragmentation Subheaders, is 

Extended 

1 = Extended 

0 = not Extended. Applicable to connections where ARQ is not enabled 


#2 


Fragmentation subheader 
1 = present, 0 = absent 


#1 


Packing subheader 
1 = present, 0 = absent 


m 

least significant bit (LSB) 


Downlink: FAST-FEEDBACK Allocation subheader 
Uplink: Grant Management subheader 
1 = present, 0 = absent 
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6.3.2.1.2 Bandwidth request header 

The Bandwidth Request PDU shall consist of bandwidth request header alone and shall not contain a 
payload. The bandwidth request header is illustrated in Figure 20. 

CD 
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Type (3) 



BR LSB (8) 

i i j i i 



i r 

CID LSB (8) 
— \ — ! — I — 1- 



i — i — i — r 

BR MSB (11) 



CID MSB (8) 



JL 



1 i I i I i 
HCS (8) 
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Figure 20— Bandwidth request header format 
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The Bandwidth Request shall have the following properties: 

a) The length of the header shall always be 6 bytes. 

b) The EC field shall be set to 0, indicating no encryption. 

c) The CID shall indicate the connection for which uplink bandwidth is requested. 

d) The Bandwidth Request (BR) field shall indicate the number of bytes requested. 

e) The allowed types for bandwidth requests are "000" for incremental and "001" for aggregate. 

An SS receiving a bandwidth request header on the downlink shall discard the PDU. 

The fields of the bandwidth request header are defined in Table 7. Every header is encoded, starting with the 
HT and EC fields. The coding of these fields is such that the first byte of a MAC header shall never have the 
value of OxFX. This prevents false detection of the stuff byte. 

Table 7— Bandwidth request header fields 



Name 


Length 
(bits) 


Description 


BR 


19 


Bandwidth Request 

The number of bytes of uplink bandwidth requested by the SS. The bandwidth request is for 
the CID. The request shall not include any PHY overhead. 


CID 


16 


Connection identifier 


EC 


1 


Always set to zero 


HCS 


8 


Header Check Sequence 

Same usage as HCS entry in Table 5 


HT 


1 


Header Type = 1 


Type 


3 


Indicates the type of bandwidth request header 
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6.3.2.2 MAC subheaders and special payloads 

Five types of subheaders may be present The per-PDU subheaders (i.e., Mesh, Fragmentation, FAST- 
FEEDBACK_AlIocation, and Grant Management) may be inserted in MAC PDUs immediately following 
the Generic MAC header. If both the Fragmentation subheader and Grant Management subheader are 
indicated, the Grant Management subheader shall come first. If the Mesh subheader is indicated, it shall 
precede all other subheaders. The FAST-FEEDBACK Allocation subheader shall always appear as the last 
per-PDU subheader. 

The only per-SDU subheader is the Packing subheader. It may be inserted before each MAC SDU if so 
indicated by the Type field. The Packing and Fragmentation subheaders are mutually exclusive and shall not 
both be present within the same MAC PDU. 

When present, per-PDU subheaders shall always precede the first per-SDU subheader. 
6.3.2.2.1 Fragmentation subheader 

The Fragmentation subheader is shown in Table 8. 



Table 8— Fragmentation subheader format 



Syntax 


Size 


Notes 


Fragmentation Subheader() { 






FC 


2 bits 


Indicates the fragmentation state of the pay load: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


if (ARQ-enabled Connection) 






BSN 


11 bits 


Sequence number of first block in the current 
SDU fragment. 


else { 






if (Type bit Extended Type) 




See Table 6 


FSN 


11 bits 


Sequence number of the current SDU fragment. 
This field increments by one (modulo 2048) for 
each fragment, including unfragmented SDUs. 


else 






FSN 


3 bits 


Sequence number of the current SDU fragment. 
This field increments by one (modulo 8) for each 
fragment, including unfragmented SDUs. 


} 






reserved 


3 bits 


Shall be set to zero 


} 
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6.3.2.2.2 Grant Management subheader 

The Grant Management subheader is two bytes in length and is used by the SS to convey bandwidth 
management needs to the BS. This subheader is encoded differently based upon the type of uplink 
scheduling service for the connection (as given by the CID). The use of this subheader is defined in 6.3.6. 
The Grant Management subheader is shown in Table 9. Its fields are defined in Table 10. The capability of 
Grant Management subheader at both BS and SS is optional. 



Table 9— Grant Management subheader format 



Syntax 


51 ze 




Grant Management Subheader() { 






if (scheduling service type = UGS) { 






SI 


Ibit 




PM 


Ibit 




reserved 


14 bits 


Shall be set to zero 


} 






else { 






Piggy Back Request 


16 bits 




} 






} 







Table 10— Grant Management subheader fields 



Name 


Length 

(bits) 


Description 


PBR 


16 


PiggyBack Request 

The number of bytes of uplink bandwidth requested by the SS. The bandwidth request is for 
the CID. The request shall not include any PHY overhead. The request shall be incremental. 


PM 


1 


Poll-Me 

0 = No action 

1 = Used by the SS to request a bandwidth poll. 


SI 


1 


Slip Indicator 

0 = No action 

1 = Used by the SS to indicate a slip of uplink grants relative to the uplink queue depth. 
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6.3.2.2.3 Packing subheader 

When Packing (see 6.3.3.4) is used, the MAC may pack multiple SDUs into a single MAC PDU. When 
packing variable-length MAC SDUs, the MAC precedes each one with a Packing subheader. The Packing 
subheader is defined in Table 11. 



Table 11— Packing subheader format 



Syntax 


Size 


Notes 


Packing Subheader^) { 






FC 


2 bits 


Indicates the fragmentation state of 
the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


if (ARQ-enabled Connection) 






BSN 


11 bits 


Sequence number of first block in the 
current SDU fragment. 


else { 






if (Type bit Extended Type) 




See Table 6. 


FSN 


11 bits 


Sequence number of the current SDU 
fragment. This field increments by 
one (modulo 2048) for each fragment, 
including unfragmented SDUs. 


else 






FSN 


3 bits 


Sequence number of the current SDU 
fragment. This field increments by 
one (modulo 8) for each fragment, 
including unfragmented SDUs. 


} 






Length 


11 bits 




} 







6.3.2.2.4 ARQ feedback 

If the ARQ Feedback Payload bit in the MAC Type field (see Table 6) is set, the ARQ Feedback Payload 
shall be transported. If packing is used, it shall be transported as the first packed payload. See 6.3.3.4.3. 
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6.3.2.2.5 Mesh subheader 

The Mesh subheader is specified in Table 12. When using Mesh mode, the Mesh subheader always follows 
the generic MAC header as specified in 63.2.2. 



Table 12— Mesh subheader format 



Syntax 


Size 


Notes 


Mesh Subheader { 






Xmt Node Id 


16 bits 




} 







6.3.2.2.6 FAST-FEEDBACK allocation subheader 

The format of the FAST-FEEDBACK allocation subheader is specified in Table 13. The FAST-FEEDBACK 
allocation subheader, when used, shall always be the last per-PDU subheader as specified in 6.3.2.2. The 
support of the FAST-FEEDBACK allocation subheader is PHY specification specific. 

Table 13— FAST-FEEDBACK allocation subheader format 



Syntax 


Size 


Notes 


FAST-FEEDBACK allocation Subheader { 






Allocation offset 


6 bits 




Feedback type 


2 bits 


00 - Fast DL measurement 

01 - Fast MIMO feedback, antenna #0 

10 - Fast MIMO feedback, antenna #1 

1 1 - MIMO mode and permutation mode 

feedback 


} 







Allocation offset 

Defines the offset, in units of slots, from the beginning of the FAST-FEEBACK uplink bandwidth 
allocation (8.4.5.4.9), of the slot in which the SS servicing the CID appearing in the MAC generic 
header, must send an FAST-FEEBACK feedback message for the connection associated with the 
CID value. Range of values 0 to 63. The allocation applies to the UL subframe of the next frame. 

6.3.2.3 MAC Management messages 

A set of MAC Management messages are defined. These messages shall be carried in the Payload of the 
MAC PDU. All MAC Management messages begin with a Management Message Type field and may 
contain additional fields. MAC Management messages on the Basic, Broadcast, and Initial Ranging 
connections shall neither be fragmented nor packed. MAC Management messages on the Primary 
Management Connection may be packed and/or fragmented. For the SCa, OFDM, and OFDMA PHY layers, 
management messages carried on the Initial Ranging, Broadcast, Basic, and Primary Management 
connections shall have CRC usage enabled. The format of the Management message is given in Figure 21. 
The encoding of the Management Message Type field is given in Table 14. MAC management messages 
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shall not be carried on Transport Connections. MAC management messages that have a Type value specified 
in Table 14 as "reserved" or those not containing all required parameters or containing erroneously encoded 
parameters, shall be silently discarded. 



Management 
Message Type 



Management Message Payload 



Figure 21— MAC Management message format 
Table 14 — MAC Management messages 



type 


Message name 


Message description 


Connection 


0 


UCD 


Uplink Channel Descriptor 


Broadcast 


1 


DCD 


Downlink Channel Descriptor 


Broadcast 


2 


DL-MAP 


Downlink Access Definition 


Broadcast 


3 


UL-MAP 


Uplink Access Definition 


Broadcast 


4 


RNG-REQ 


Ranging Request 


Initial Ranging or Basic 


5 


RNG-RSP 


Ranging Response 


Initial Ranging or Basic 


6 


REG-REQ 


Registration Request 


Primary Management 


7 


REG-RSP 


Registration Response 


Primary Management 


8 




reserved 




9 


PKM-REQ 


Privacy Key Management Request 


Primary Management 


10 


PKM-RSP 


Privacy Key Management Response 


Primary Management 


11 


DSA-REQ 


Dynamic Service Addition Request 


Primary Management 


12 


DSA-RSP 


Dynamic Service Addition Response 


Primary Management 


13 


DSA-ACK 


Dynamic Service Addition Acknowledge 


Primary Management 


14 


DSC-REQ 


Dynamic Service Change Request 


Primary Management 


15 


DSC-RSP 


Dynamic Service Change Response 


Primary Management 


16 


DSC-ACK 


Dynamic Service Change Acknowledge 


Primary Management 


17 


DSD-REQ 


Dynamic Service Deletion Request 


Primary Management 


18 


DSD-RSP 


Dynamic Service Deletion Response 


Primary Management 


19 




reserved 




20 




reserved 




21 


MCA-REQ 


Multicast Assignment Request 


Primary Management 


22 


MCA-RSP 


Multicast Assignment Response 


Primary Management 


23 


DBPC-REQ 


Downlink Burst Profile Change Request 


Basic 


24 


DBPC-RSP 


Downlink Burst Profile Change Response 


Basic 


25 


RES-CMD 


Reset Command 


Basic 
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Table 14— MAC Management messages (continued) 



Type 


Message name 


Message description 


Connection 


26 


SBC-REQ 


SS Basic Capability Request 


Basic 


27 


SBC-RSP 


SS Basic Capability Response 


Basic 


28 


CLK-CMP 


SS network clock comparison 


Broadcast 


29 


DREG-CMD 


De/Re-register Command 


Basic 


30 


DSX-RVD 


DSx Received Message 


Primary Management 


31 


TFTP-CPLT 


Config File TFTP Complete Message 


Primary Management 


32 


TFTP-RSP 


Config File TFTP Complete Response 1 


Primary Management 


33 


ARQ-Feedback 


Standalone ARQ Feedback 


Basic 


34 


ARQ-Discard 


ARQ Discard message 


Basic 


35 


ARQ-Reset 


ARQ Reset message 


Basic 


36 


REP-REQ 


Channel measurement Report Request 


Basic 


37 


REP-RSP 


Channel measurement Report Response 


Basic 


38 


FPC 


Fast Power Control 


Broadcast 


39 


MSH-NCFG 


Mesh Network Configuration 


Broadcast 


40 


MSH-NENT 


Mesh Network Entry 


Basic 


41 


MSH-DSCH 


Mesh Distributed Schedule 


Broadcast 


42 


MSH-CSCH 


Mesh Centralized Schedule 


Broadcast 


43 


MSH-CSCF 


Mesh Centralized Schedule Configuration 


Broadcast 


44 


AAS-FBCK-REQ 


AAS Feedback Request 


• Basic ] 


45 


AAS-FBCK-RSP 


AAS Feedback Response 


Basic 


46 


AAS_Beam_Select 


AAS Beam Select message 


Basic 


47 


AAS_BEAM_REQ 


AAS Beam Request message 


Basic 


48 


AAS_BEAM_RSP 


AAS Beam Response message 


Basic 


49 


DREG-REQ 


SS De-registration message 


Basic 


50-255 




reserved 





During the adaptive antenna system (AAS) portion of the frame, DL-MAP, UL-MAP, DCD, UCD, and 
CLK-CMP messages may be sent using the basic CID. 
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6.3.2.3.1 Downlink Channel Descriptor (DCD) message 



A DCD shall be transmitted by the BS at a periodic interval (Table 342) to define the characteristics of a 
downlink physical channel. 

Table 15— DCD message format 



Syntax 


Size 


Notes 








1 lTlctllagcIIlcIll ivicaawigc Kyyv — ± 






Downlink channel ID 


8 bits 




Configuration Change Count 


8 bits 




TLV Encoded information for the overall channel 


variable 


TLV specific 


Begin PHY Specific Section { 




See applicable PHY section 


for (i= 1; i <=/i;/++) { 




For each downlink burst profile 1 to 
n 


Downlink_Burst_Profile 




PHY specific 


} 






! } 






} 







A BS shall generate DCDs in the format shown in Table 15, including all of the following parameters: 
Configuration Change Count 

Incremented by one (modulo 256) by the BS whenever any of the values of this channel descriptor 
change. If the value of this count in a subsequent DCD remains the same, the SS can quickly decide 
that the remaining fields have not changed and may be able to disregard the remainder of the 
message. 

Downlink Channel ID 

The identifier of the downlink channel to which this message refers. This identifier is arbitrarily 
chosen by the BS and is unique only within the MAC domain. This acts as a local identifier for 
transactions such as ranging. 

The following WirelessMAN-OFDM PHY-specific parameter shall be included in the DCD message: 

Frame Duration Code 
Frame Number 

The message parameters following the Configuration Change Count shall be encoded in a TLV form 
(see 11.4). All channel encodings (see 11.4.1) shall appear first before the Downlink_Burst_Profile 
encodings. 

The Downlink_Burst_Profile is a compound TLV encoding that defines, and associates with a particular 
Downlink Interval Usage Code (DIUC), the PHY characteristics that shall be used with that DIUC. Within 
each Downlink_Burst_Profile shall be an unordered list of PHY attributes, encoded as TLV values (see 
11.4.2). Each interval is assigned a DIUC by the DL-MAP message. A Downlink_Burst_Profile shall be 
included for each DIUC to be used in the DL-MAP unless the PHY's Downlink_Burst_Profile is explicitly 
known. 

Downlink_Burst_Profile contents are defined separately for each PHY specification in Clause 8. 
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6.3.2.3.2 Downlink map (DL-MAP) message 

The DL-MAP message defines the access to the downlink information. If the length of the DL-MAP 
message is a non-integral number of bytes, the LEN field in the MAC header is rounded up to the next 
integral number of bytes. The message shall be padded to match this length, but the SS shall disregard the 
four pad bits. 

A BS shall generate DL-MAP messages in the format shown in Table 16, including all of the following 
parameters: 

PHY Synchronization 

The PHY synchronization field is dependent on the PHY specification used. The encoding of this 
field is given in each PHY specification separately. 
DCD Count 

Matches the value of the configuration change count of the DCD, which describes the downlink 
burst profiles that apply to this map. 
Base Station ID 

The Base Station ID is a 48-bit long field identifying the BS. The Base Station ID shall be 
programmable. The most significant 24 bits shall be used as the operator ID. This is a network 
management hook that can be combined with the Downlink Channel ID of the DCD message for 
handling edge-of-sector and edge-of-cell situations. 

The encoding of the remaining portions of the DL-MAP message is PHY- specification dependent and may 
be absent. Refer to the appropriate PHY specification. 



Table 16— DL-MAP message format 



Syntax 


Size 


Notes 


DL-MAP_Message_Format() { 






Management Message Type = 2 


8 bits 




PHY Synchronization Field 


variable 


See appropriate PHY specification. 


j DCD Count 


8 bits 




Base Station ID 


48 bits 




Begin PHY Specific Section { 




See applicable PHY section. 


for (/= 1; i <= n; /++) { 




For each DL-MAP element 1 to n. 


DL-MAP JE() 


variable 


See corresponding PHY specification. 


} 






} 






if ! (byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary. 


} 






} 







46 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



6.3.2.3.3 Uplink Channel Descriptor (UCD) message 

A UCD shall be transmitted by the BS at a periodic interval (Table 342) to define the characteristics of an 
uplink physical channel. 

A BS shall generate UCDs in the format shown in Table 17, including all of the following parameters: 
Configuration Change Count 

Incremented by one (modulo 256) by the BS whenever any of the values of this channel descriptor 
change: If the value of this count in a subsequent UCD remains the same, the SS can quickly decide 
that the remaining fields have not changed and may be able to disregard the remainder of the 
message. This value is also referenced from the UL-MAP messages. 
Ranging Backoff Start 

Initial backoff window size for initial ranging contention, expressed as a power of 2. Values of 
n range 0-1 5 (the highest order bits shall be unused and set to 0). 
Ranging Backoff End 

Final backoff window size for initial ranging contention, expressed as a power of 2. Values of 
n range 0-15 (the highest order bits shall be unused and set to 0). 
Request Backoff Start 

Initial backoff window size for contention BW requests, expressed as a power of 2. Values of n 
range 0-15 (the highest order bits shall be unused and set to 0). 
Request Backoff End 

Final backoff window size for contention BW requests, expressed. as a power of 2. Values of n 
range 0-15 (the highest order bits shall be unused and set to 0). 



Table 17— UCD message format 



Syntax 


Size 


Notes 


UCD_Message_Format() { 






Management Message Type = 0 


8 bits 




Configuration Change Count 


8 bits 




Ranging Backoff Start 


8 bits 




Ranging Backoff End 


8 bits 




Request Backoff Start 


8 bits 




Request Backoff End 


8 bits 




TLV Encoded information for the overall channel 


variable 


TLV specific. 


Begin PHY Specific Section { 




See applicable PHY section. 


for (/ = 1; i <= n; /++) { 




For each uplink burst profile 1 to n. 


Uplink_Burst_Profile 


variable 


PHY specific. 


} 






! i 






} 







To provide for flexibility, the remaining message parameters shall be encoded in a TLV form (see 11.3). All 
Channel encodings (see 11.3.1) shall appear first before the Uplink_Burst_Profile encodings. 



The Uplink_Burst_Profile is a compound TLV encoding that defines, and associates with a particular UIUC, 
the PHY characteristics that shall be used with that UIUC. Within each Uplink_Burst_Profile shall be an 
unordered list of PHY attributes, encoded as TLV values (see 11.3.1.1 for an example applicable to the 
10-66 GHz PHY specification). Each interval is assigned a UIUC by the UL-MAP message. An 
Uplink_Burst_Profile shall be included for each UIUC to be used in the UL-MAP. 

UplinkJBurst_Profile contents are defined separately for each PHY specification in Clause 8. 



Copyright ©2004 IEEE. All rights reserved. 



47 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



6.3.2.3.4 Uplink map (UL-MAP) message 

The UL-MAP message allocates access to the uplink channel. The UL-MAP message shall be as shown in 
Table 18. 



Table 18— UL-MAP message format 



Syntax 


Size 


Notes 


UL-MAP_Message_Format() { 






Management Message Type = 3 


8 bits 




Uplink Channel ID 


8 bits 




UCD Count 


8 bits 




Allocation Start Time 


32 bits 




Begin PHY Specific Section { 




See applicable PHY section. 


for (i= l;/<=n;i++) { 




For each UL-MAP element 1 to n. 


UL-MAP JE() 


variable 


See corresponding PHY specification. 


} 






} 






if Kbyte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary. 


} 






} 







The BS shall generate the UL-MAP with the following parameters: 
Uplink Channel ID 

The identifier of the uplink channel to which this message refers. 
UCD Count 

Matches the value of the Configuration Change Count of the UCD, which describes the uplink 
burst profiles that apply to this map. 
Allocation Start Time 

Effective start time of the uplink allocation defined by the UL-MAP 
(units are PHY-specific, see 10.3). 
Map IEs 

The contents of a UL-MAP IE is PHY-specification dependent. 

IEs define uplink bandwidth allocations. Each UL-MAP message shall contain at least one IE that marks the 
end of the last allocated burst. Ordering of IEs carried by the UL-MAP is PHY-specific. 

The CID represents the assignment of the IE to either a unicast, multicast, or broadcast address. When 
specifically addressed to allocate a bandwidth grant, the CID shall be the Basic CID of the SS. A UIUC shall 
be used to define the type of uplink access and the uplink burst profile associated with that access. An 
Uplink_Burst_Profile shall be included in the UCD for each UIUC to be used in the UL-MAP. 
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6.3.2.3.5 Ranging request (RNG-REQ) message 

An RNG-REQ shall be transmitted by the SS at initialization and periodically to determine network delay 
and to request power and/or downlink burst profile change. The format of the RNG-REQ message is shown 
in Table 19. The RNG-REQ message may be sent in Initial Ranging and data grant intervals. 



Table 19 — RNG-REQ message format 



Syntax 


Size 


Notes 1 


RNG-REQ_Message_Format() { 






Management Message Type = 4 


8 bits 




Downlink Channel ID 


8 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







The CID field in the MAC header shall assume the following values when sent in an Initial Ranging interval: 

a) Initial ranging CID if the SS is attempting to join the network. 

b) Initial ranging CID if the SS has not yet registered and is changing downlink (or both downlink and 
uplink) channels. 

c) In all other cases, the Basic CID is used as soon as one is assigned in the RNG-RSP message. 
If sent in a data grant interval, the CID is always equal to the Basic CID. 

An SS shall generate RNG-REQ messages in the format shown in Table 19, including the following 
parameter: 

Downlink Channel ID 

The identifier of the downlink channel on which the SS received the UCD describing the uplink on 
which this ranging request message is to be transmitted. This is an 8-bit field. 

All other parameters are coded as TLV tuples as defined in 11.5. 

The following parameters shall be included in the RNG-REQ message when the SS is attempting to join the 
network: 

Requested Downlink Burst Profile 
SS MAC Address 

The following parameters shall be included in the RNG-REQ message when transmitted during initial 
ranging on the SS's Basic connection: 

MAC Version (11.1.3) 

The following parameters may be included in the RNG-REQ message after the SS has received an RNG- 
RSP addressed to the SS: 

Requested Downlink Burst Profile 
Ranging Anomalies 

The following parameter may be included in the RNG-REQ message: 

AAS broadcast capability 
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6.3.2.3.6 Ranging response (RNG-RSP) message 

An RNG-RSP shall be transmitted by the BS in response to a received RNG-REQ. In addition, it may also 
be transmitted asynchronously to send corrections based on measurements that have been made on other 
received data or MAC messages. As a result, the SS shall be prepared to receive an RNG-RSP at any time, 
not just following an RNG-REQ transmission. 

To provide for flexibility, the message parameters following the Uplink Channel ID shall be encoded in a 
TLV form. 

A BS shall generate RNG-RSPs in the form shown in Table 20, including all of the following parameters: 
Uplink Channel ID 

The identifier of the uplink channel on which the BS received the RNG-REQ to which this 
response refers. This is an 8-bit quantity. 

All other parameters are coded as TLV tuples, as defined in 11.6. 



Table 20— RNG-RSP message format 



Syntax 


Size 


Notes 


RNG-RSP_Message_Format() { 






Management Message Type = 5 


8 bits 




Uplink Channel ID 


8 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







The following parameters shall be included in the RNG-RSP message: 



Ranging Status 

The following parameters may be included in the RNG-RSP message: 
Timing Adjust Information 

If this field is not included, no adjustment shall be made 
Power Adjust Information 

If this field is not included, no adjustment shall be made 
Downlink Frequency Override 
Uplink Channel ID Override 
Downlink Operational Burst Profile 
Basic CID 

A required parameter if the RNG-RSP message is being sent on the Initial Ranging CID in response 
to a RNG-REQ message that was sent on the Initial Ranging CID. 
Primary Management CID 

A required parameter if the RNG-RSP message is being sent on the Initial Ranging CID in response 
to a RNG-REQ message that was sent on the Initial Ranging CID. 
SS MAC Address (48-bit) 

A required parameter when the CID in the MAC header is the Initial Ranging CID. 
Frequency Adjust Information 
AAS broadcast permission 
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The following WirelessMAN-SCa or WirelessMAN-OFDM PHY-specific parameters may also be included 
in the RNG-RSP message: 

Frame Number 

Frame number in which the corresponding RNG-REQ message or subchannelized initial ranging 
indication (for OFDM) was received. When Frame Number is included, SS MAC Address shall not 
appear in the same message. 
Initial Ranging Opportunity Number 

Initial Ranging opportunity within the frame in which the corresponding RNG-REQ message or 
subchannelized initial ranging indication (for OFDM) was received. If not provided, and Frame 
Number is included in the message, Initial Ranging Opportunity is assumed to be one. 

The following WirelessMAN-OFDM PHY-specific parameter may also be included in the RNG-RSP 

message: 

Ranging Subchannel 

The OFDM ranging subchannel index that was used to transmit the initial ranging message. 

The following WirelessMAN-OFDMA PHY specific parameters shall be included in the RNG-RSP 
message when an initial ranging message based on code division multiple access (CDMA) is received, in 
which case the RNG-RSP shall use the initial ranging CID. 

Ranging code attributes 

Indicates the OFDMA time symbols reference, subchannel reference, and frame number used to 
transmit the ranging code, and the ranging code index that was sent by the SS. 

6.3.2.3.7 Registration request (REG-REQ) message 

An REG-REQ shall be transmitted by an SS at initialization. An SS shall generate REG-REQs in the form 
shown in Table 21. 



} Table 21— REG-REQ message format 



Syntax 


Size 


Notes 


REG-REQ_Message_Format() { 






Management Message Type = 6 


8 bits 




TLV Encoded Information 


variable 


TLV Specific 


} 







An SS shall generate REG-REQs including the following parameters: 
Primary Management CID (in the generic MAC header) 

The CID in the generic MAC header is the Primary Management CID for this SS, as assigned in the 
RNG-RSP message. 

All other parameters are coded as TLV tuples. 
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The REG-REQ shall contain the following TLVs: 

Hashed Message Authentication Code (HM AC) Tuple 

Shall be final attribute in the message's TLV attribute list (11.1.2). 
In Mesh Mode, message digest is calculated using HMAC_KEY_U. 

For PMP operation, the REG-REQ shall contain the following TLVs: 

Uplink CID Support (11,7.6) 
SS management support (11,7,2) 
IP management mode (11,7.3) 

In Mesh Mode, the REG-REQ shall contain the following TLVs: 

SS MAC Address 
MAC Version (11.1.3) 

The MAC version implemented in the Candidate Node. 

The REG-REQ may contain the following TLVs: 

IP Version (11.7.4) 
SS Capabilities Encodings (11.7.8) 
Vendor ID Encoding (11.1.5) 
Vendor-specific information (11.1.6) 
Convergence Sublayer Capabilities (11.7.7) 
ARQ Parameters (11.7.1) 

ARQ and fragmentation parameters desired by the SS for establishing the secondary management 
connection. When the TLV is not supplied, the SS is indicating its desire to not support ARQ on the 
connection. For purposes of the parameter negotiation dialog, the parameters supplied in this 
message are equivalent to those supplied in the DSA-REQ message. 

6.3.2.3.8 Registration response (REG-RSP) message 

A REG-RSP shall be transmitted by the BS in response to received REG-REQ. 

To provide for flexibility, the message parameters following the response field shall be encoded in a TLV 
format. 

A BS shall generate REG-RSPs in the form shown in Table 22, including both of the following parameters: 
CID ( in the generic MA C header) 

The CID in the generic MAC header is the Primary Management CID for this SS. 
Response 

A 1 byte quantity with one of the two values: 

0 = OK 

1 = Message authentication failure 
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Table 22— REG-RSP message format 



Syntax 


Size 


Notes 


REG-RSP_Message_Format() { 






Management Message T^pe = 7 


8 bits 




Response 


8 bits 




TLV Encoded Information 

} 


variable 


TLV specific 



The REG-RSP shall contain the following TLVs: 



SS management support (11.7.2) 

Response to REG-REQ indicating the mode of SS management operation. 
Secondary Management CID (11.7.5) 

Present only if the SS has indicated in the REG-REQ that it is a managed SS. 
HMAC T\iple (11.1.2) 

The HMAC Tuple attribute shall be the final attribute in the message's TLV attribute list. 
In Mesh Mode, message digest is calculated using HMAC_KEY_D. 

In Mesh Mode, the REG-RSP shall contain the following TLVs: 

Node ID 

MAC Version (11.1.3) 

MAC Version used in the network 

The REG-RSP may contain the following TLVs: 
SS Capabilities Encodings (11.7.8) 

Response to the capabilities of the requester provided in the REG-REQ. Included in the response if 
the request included capabilities information. The response indicates whether or not the capabilities 
may be used. If a capability is not recognized, the response indicates that this capability shall not be 
used by the requester. Capabilities returned in the REG-RSP shall not be set to require greater 
capability of the requester than is indicated in the REG-REQ. 
IP Version (11.7.4) 

Vendor ID Encoding (of the responder; 11.1.5) 
Vendor-specific information (11.1.6) 

Included if the RNG-REQ contained the Vendor ID Encoding of the requestor. 
ARQ Parameters (11.7.1) 

ARQ and fragmentation parameters specified by the BS to complete ARQ parameter negotiation 
for the secondary management connection. This information is only included in the message if 
ARQ Parameters where supplied by the SS in the original REG-REQ message. For purposes of the 
parameter negotiation dialog, the parameters supplied in this message are equivalent to those 
supplied in the DSA-RSP message. 
IP management mode (11.7.3) 

Response to REG-REQ indication of whether or not the requester wishes to accept IP-based traffic 
on the Secondary Management Connection, once the initialization process has completed. 
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6.3.2.3.9 Privacy key management (PKM) messages (PKM-REQ/PKM-RSP) 

PKM employs two MAC message types: PKM Request (PKM-REQ) and PKM Response (PKM-RSP), as 
described in Table 23. 



Table 23— PKM MAC messages 



Type Value 


Message name 


Message description 


9 


PKM-REQ 


Privacy Key Management Request [SS -> BS] 


10 


PKM-RSP 


Privacy Key Management Response [BS -> SS] 



These MAC management message types distinguish between PKM requests (SS-to-BS) and PKM 
responses (BS-to-SS). Each message encapsulates one PKM message in the Management Message 
Payload. 

PKM protocol messages transmitted from the SS to the BS shall use the form shown in Table 24. They are 
transmitted on the SSs Primary Management Connection. 



Table 24— PKM request (PKM-REQ) message format 



Syntax 


Size 


Notes 


PKM-REQ_Message_Format() { 






Management Message Type = 9 


8 bits 




Code 


8 bits 




PKM Identifier 


8 bits 




TLV Encoded Attributes 


variable 


TLV specific 


} 







PKM protocol messages transmitted from the BS to the SS shall use the form shown in Table 25. They are 
transmitted on the SSs Primary Management Connection. 



Table 25— PKM response (PKM-RSP) message format 



Syntax 


Size 


Notes | 


PKM-RSP_Message_Format() { 






Management Message Type = 10 


8 bits 




Code 


8 bits 




PKM Identifier 


8 bits 




TLV Encoded Attributes 


variable 


TLV specific 


} 
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The parameters shall be as follows: 
Code 

The Code is one byte and identifies the type of PKM packet. When a packet is received with an 
invalid Code, it shall be silently discarded. The code values are defined in Table 26. 

PKM Identifier 

The Identifier field is one byte. An SS uses the identifier to match a BS response to the SS's 
requests. 

The SS shall increment (modulo 256) the Identifier field whenever it issues a new PKM message. 
A "new" message is an Authorization Request or Key Request that is not a retransmission being 
sent in response to a Timeout event. For retransmissions, the Identifier field shall remain 
unchanged. 

The Identifier field in Authentication Information messages, which are informative and do not 
effect any response messaging, shall be set to zero. The Identifier field in a BS's PKM-RSP 
message shall match the Identifier field of the PKM-REQ message the BS is responding to. The 
Identifier field in TEK Invalid messages, which are not sent in response to PKM-REQs, shall be set 
to zero. The Identifier field in unsolicited Authorization Invalid messages shall be set to zero. 

On reception of a PKM-RSP message, the SS associates the message with a particular state 
machine (the Authorization state machine in the case of Authorization Replies, Authorization 
Rejects, and Authorization Invalids; a particular TEK state machine in the case of Key Replies, 
Key Rejects, and TEK Invalids). 

An SS shall keep track of the identifier of its latest, pending Authorization Request. The SS shall 
discard Authorization Reply and Authorization Reject messages with Identifier fields not matching 
that of the pending Authorization Request. 

An SS shall keep track of the identifiers of its latest, pending Key Request for each SA. The SS 
shall discard Key Reply and Key Reject messages with Identifier fields not matching those of the 
pending Key Request messages. 

Attributes 

PKM . attributes carry the specific authentication, authorization, and key management data 
exchanged between client and server. Each PKM packet type has its own set of required and 
optional attributes. Unless explicitly stated, there are no requirements on the ordering of attributes 
within a PKM message. The end of the list of attributes is indicated by the LEN field of the MAC 
PDU header. 



Table 26— PKM message codes 



Code 


PKM message type 


MAC Management 
message name 


0-2 


reserved 




3 


SA Add 


PKM-RSP 


4 


Auth Request 


PKM-REQ 


5 


Auth Reply 


PKM-RSP 


6 


Auth Reject 


PKM-RSP 
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Table 26— PKM message codes (continued) 



Code 


PKM message type 


MAC Management 
message name 


7 


Key Request 


PKM-REQ 


8 


Key Reply 


PKM-RSP 


9 


Key Reject 


PKM-RSP 


10 


Auth Invalid 


PKM-RSP 


11 


TEK Invalid 


PKM-RSP 


12 


Auth Info 


PKM-REQ 


13-255 


reserved 





Formats for each of the PKM messages are described in the following subclauses. The descriptions list the 
PKM attributes contained within each PKM message type. The attributes themselves are described in 11.9. 
Unknown attributes shall be ignored on receipt and skipped over while scanning for recognized attributes. 

The BS shall silently discard all requests that do not contain ALL required attributes. The SS shall silently 
discard all responses that do not contain ALL required attributes. 

6.3.2.3.9.1 SA Add message 

This message is sent by the BS to the SS to establish one or more additional SAs. 
Code: 3 

Attributes are shown in Table 27. 



Table 27— SA Add attributes 



Attribute 


Contents 


Key-Sequence-Number 


Authorization key (AK) sequence number. 


(one or more) SA- 
Descriptor(s) 


Each compound S A-Descriptor attribute specifies an SA identifier (SAID) 
and additional properties of the SA. 


HMAC-Digest 


Keyed secure hash algorithm (SHA) message. 



The HMAC-Digest attribute shall be the final attribute in the message's attribute list. 
6.3.2.3.9.2 Authorization Request (Auth Request) message 

Code: 4 

Attributes are shown in Table 28. 
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Table 28— Auth Request attributes 



Attribute 


Contents 


SS-Certificate 


Contains the SS's X.509 user certificate. 


Security-Capabilities 


Describes requesting SS's security capabilities. j 


SAID 


SS's primary SAID equal to the Basic CID. 



The SS-certificate attribute contains an X.509 SS certificate (see 7.6) issued by the SS's manufacturer. The 
SS's X.509 certificate is a public-key certificate that binds the SS's identifying information to its RSA public 
key in a verifiable manner. The X.509 certificate is digitally signed by the SS's manufacturer, and that 
signature can be verified by a BS that knows the manufacturer's public key. The manufacturer's public key 
is placed in an X.509 certification authority (CA) certificate, which in turn is signed by a higher-level CA. 

The Security-Capabilities attribute is a compound attribute describing the requesting SS's security 
capabilities. This includes the data encryption and data authentication algorithms the SS supports. 

An SAID attribute contains a Privacy SAID. In this case, the provided SAID is the SS's Basic CID, which is 
equal to the Basic CID assigned to the SS during initial ranging. 

6.3.2.3.9.3 Authorization Reply (Auth Reply) message 

Sent by the BS to a client SS in response to an Authorization Request, the Authorization Reply message 
contains an AK, the key's lifetime, the key's sequence number, and a list of SA-Descriptors identifying the 
Primary and Static SAs that the requesting SS is authorized to access and their particular properties (e.g., 
type, cryptographic suite). The AK shall be encrypted with the SS's public key. The SA-Descriptor list shall 
include a descriptor for the Basic CID reported to the BS in the corresponding Auth Request. The SA- 
Descriptor list may include descriptors of Static SAIDs that the SS is authorized to access. 

The Auth Reply may also contain PKM configuration settings that override the default timer values. 
Code:5 

Attributes are shown in Table 29. 



Table 29— Auth Reply attributes 



Attribute 


Contents 


AUTH-Key 


Authorization (AUTH) Key, encrypted with the target client SS's public key. 


Key-Lifetime 


AK's active lifetime. 


Key-Sequence-Number 


AK sequence number. 


(one or more) SA- 
Descriptor(s) 


Each compound SA-Descriptor attribute specifies an SAID and additional properties of 
the SA. 


PKM Configuration 
settings (optional) 


PKM timer values. 


Operator Shared Secret 


Mesh Mode Only. Key known to all. 


Key-Sequence-Number 


Mesh Mode Only. Sequence number of the Operator Shared Secret. 


Key-Lifetime 


Mesh Mode Only. Lifetime of the Operator Shared Secret. 
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6.3.2.3.9.4 Authorization Reject (Auth Reject) message 

The BS responds to an SS's authorization request with an Authorization Reject message if the BS rejects the 
SS's authorization request. 

Code: 6 

Attributes are shown in Table 30. 



Table 30— Auth Reject attributes 



Attribute 


Contents 


Error-Code 


Error code identifying reason for rejection of authorization request. 


Display-String (optional) 


Display String providing reason for rejection of authorization request. 



The Error-Code and Display-String attributes describe to the requesting SS the reason for the authorization 
failure. 

6.3.2.3.9.5 Key Request message 

Code: 1 

For PMP operations, attributes are shown in Table 31. 



Table 31— Key Request attributes 



Attribute 


Contents 


Key-Sequence-Number 


AK sequence number. 


SAID 


Security association identifier. 


HMAC-Digest 


Keyed SHA message digest. 



When operating in Mesh Mode, the attributes of the Key Request message shall be those of Table 32. 



Table 32— Key Request attributes for Mesh Mode 



Attribute 


Contents 


SS Certificate 


X.509 Certificate of the Node. 


SAID 


SA identifier. ! 


HMAC-Digest 


HMAC using HMAC_KEY_S. 



The HMAC-Digest attribute shall be the final attribute in the message's attribute list. 
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Inclusion of the keyed digest allows the BS to authenticate the Key Request message. The HMAC-Digest's 
authentication key is derived from the AK or Operator Shared Secret. 

6.3.2.3.9.6 Key Reply message 

Code: 8 

Attributes are shown in Table 33. 



Table 33— Key Reply attributes 



Attribute 


Contents 


Key-Sequence-Number 


AK sequence number. 


SAID 


Security Association ID. 


TEK-Parameters 


"Older" generation of key parameters relevant to SAID. 


TEK- Parameters 


"Newer" generation of key parameters relevant to SAID. 


HMAC-Digest 


Keyed SHA message digest. 



The TEK-Parameters attribute is a compound attribute containing all of the keying material corresponding to 
a particular generation of an SAID's TEK. This would include the TEK, the TEK's remaining key lifetime, 
its key sequence number, and the cipher block chaining (CBC) initialization vector. The TEK is encrypted. 
See 11.9.8 for details. 

At all times the BS maintains two sets of active generations of keying material per SAID. (A set of keying 
material includes a TEK and its corresponding CBC initialization vector.) One set corresponds to the "older" 
generation of keying material, the second set corresponds to the "newer" generation of keying material. The 
newer generation has a key sequence number one greater than (modulo 4) that of the older generation. 
Subclause 7.4.1 specifies BS requirements for maintaining and using an SAID's two active generations of 
keying material. 

The BS distributes to a client SS both generations of active keying material. Thus, the Key Reply message 
contains two TEK-Parameters attributes, each containing the keying material for one of the SAID's two 
active sets of keying material. 

The HMAC-Digest attribute shall be the final attribute in the message's attribute list. 

Inclusion of the keyed digest allows the receiving client to authenticate the Key Reply message and ensure 
SS and BS have synchronized AKs. The HMAC-Digest's authentication key is derived from the AK. See 7.5 
for details. 

6.3.2.3.9.7 Key Reject message 

Receipt of a Key Reject indicates the receiving client SS is no longer authorized for a particular SAID. 
Code: 9 
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Attributes are shown in Table 34. 



Table 34— Key Reject attributes 



Attribute 


Contents 


Key-Sequence-Number 


AK sequence number. 


SAID 


Security Association ID. 


Error-Code 


Error code identifying reason for rejection of Key Request. 


Display-String (optional) 


Display string containing reason for Key Reject. 


HMAC-Digest 


Keyed SHA message digest. 



The HMAC-Digest attribute shall be the final attribute in the message's attribute list. 

Inclusion of the keyed digest allows the receiving client to authenticate the Key Reject message and ensure 
SS and BS have synchronized AKs. The HMAC-Digest's authentication key is derived from the AK. See 7.5 
for details. 

6.3.2.3.9.8 Authorization Invalid message 

The BS may send an Authorization Invalid message to a client SS as: 

a) An unsolicited indication, or 

b) A response to a message received from that SS. 

In either case, the Authorization Invalid message instructs the receiving SS to reauthorize with its BS. 

The BS sends an Authorization Invalid in response to a Key Request if (1) the BS does not recognize the SS 
as being authorized (i.e., no valid AK associated with the requesting SS) or (2) verification of the Key 
Request's keyed message digest (in HMAC-Digest attribute) failed, indicating a loss of AK synchronization 
between SS and BS. 

Code: 10 

Attributes are shown in Table 35. 



Table 35— Authorization Invalid attributes 



Attribute 


Contents 


Error-Code 


Error code identifying reason for Authorization Invalid. 


Display-String (optional) 


Display String describing failure condition. 
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6.3.2.3.9.9 TEK Invalid message 

The BS sends a TEK Invalid message to a client SS if the BS determines that the SS encrypted an uplink 
PDU with an invalid TEK (i.e., an SAID's TEK key sequence number), contained within the received 
packet's MAC Header, is out of the BS's range of known, valid sequence numbers for that SAID. 

Code: 11 

Attributes are shown in Table 36. 



Table 36— TEK Invalid attributes 



Attribute 


Contents 


Key -Sequence-Number 


AK sequence number. 


SAID 


Security Association ID. 


Error-Code 


Error code identifying reason for TEK Invalid message. 


Display-String (optional) 


Display string containing vendor-defined information. 


HMAC-Digest 


Keyed SHA message digest. 



The HMAC-Digest attribute shall be the final attribute in the message's attribute list. 

Inclusion of the keyed digest allows the receiving client to authenticate the TEK Invalid message and ensure 
SS and BS have synchronized AKs. The HMAC-Digest's authentication key is derived from the AK. See 7.5 
for details. 

6.3.2.3.9.10 Authentication Information (Auth Info) message 

The Auth Info message contains a single CA-Certificate attribute, containing an X.509 CA certificate for the 
manufacturer of the SS. The SS's X.509 user certificate shall have been issued by the CA identified by the 
X.509 CA certificate. 

Auth Info messages are strictly informative; while the SS shall transmit Auth Info messages as indicated by 
the Authentication state model (7.2.4), the BS may ignore them. 

Code: 12 

Attributes are shown in Table 37. 



Table 37— Auth Info attributes 



Attribute 


Contents 


CA-Certificate 


Certificate of manufacturer CA that issued SS certificate. 



The CA-certificate attribute contains an X.509 CA certificate for the CA that issued the SS's X.509 user 
certificate. The external CA issues these CA certificates to SS manufacturers. 
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6.3.2.3.10 DSA-REQ message 

A DSA-REQ is sent by an SS or BS to create a new service flow. 



Table 38— DSA-REQ message format 



Syntax 


Size 


Notes 


DSA-REQ_Message_Format() { 






Management Message Type = 11 


8 bits 




Transaction ID 


16 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







An SS or BS shall generate DSA-REQ messages in the form shown in Table 38, including the following 
parameters: 

CID (in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Unique identifier for this transaction assigned by the sender. 
All other parameters are coded as TLV tuples. 

A DSA-REQ message shall not contain parameters for more than one service flow. 
The DSA-REQ message shall contain the following: 
Service Flow Parameters (see 11.13) 

Specification of the service flow's traffic characteristics and scheduling requirements. 
Convergence Sublayer Parameter Encodings (see 11.13.19) 

Specification of the service flow's CS specific parameters 
HMAC Tbple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 

6.3.2.3.10.1 SS-lnitiated DSA 

Service Flow ID shall not be present in the DSA message; at the BS the service flow within the DSA-REQ 
shall be assigned a unique Service Flow ID, which will be sent back in the DSA-RSP message. SS-initiated 
DSA-REQs may use the Service Class Name in place of some, or all, of the QoS Parameters. 

6.3.2.3.10.2 BS-lnitiated DSA 

BS-initiated DSA-REQ may also include a CID. CIDs are unique within the MAC domain. 

BS-initiated DSA-REQs for named Service Classes shall include the QoS Parameter Set associated with that 
Service Class. BS-initiated DSA-REQs shall also include the SA-Descriptor for the service flow. 
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6.3.2.3.11 DSA-RSP message 

A DSA-RSP shall be generated in response to a received DSA-REQ. The format of a DSA-RSP shall be as 
shown in Table 39. 



Table 39— DSA-RSP message format 



Syntax 


Size 


Notes 


DSA-RSP_Message_Format() { 






Management Message l^pe = 12 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







Parameters shall be as follows: 

CD) (in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Transaction ID from corresponding DSA-REQ. 
Confirmation Code (see 11.13) 

The appropriate Confirmation Code (CC) for the entire corresponding DSA-REQ. 
All other parameters are coded as TLV tuples. 

If the transaction is successful, the DSA-RSP may contain the following: 
Service Flow Parameters (see 11.13) 

The complete specification of the service flow shall be included in the DSA-RSP if it includes a 
newly assigned CID or an expanded Service Class Name or to point to specific parameter that 
caused rejection of connection creation (only in the case CC = "reject-notsupported-parameter- 
value" or "reject-not-supported-parameter"). 
CS Parameter Encodings (see 1 LI 3. 19) 
Specification of the service flow's CS specific parameters. 

If the transaction is unsuccessful, the DSA-RSP shall include: 

Service Flow Error Set (see 11.13) 

A Service Flow Error Set and identifying service flow reference/SFID shall be included for every 
failed service flow in the corresponding DSA-REQ message. Every Service Flow Error Set shall 
include every specific failed QoS Parameter of the corresponding service flow (see 11.13). This 
parameter shall be omitted if the entire DSA-REQ is successful. 

Whether successful or unsuccessful, the message shall include the following: 
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HMAC Tuple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 

6.3.2.3.11.1 SS-lnitiated DSA 

The BS's DSA-RSP for service flows that are successfully added shall contain an SFID. The DSA-RSP for 
successfully Admitted or Active uplink QoS Parameter Sets shall also contain a CID. 

The BS's DSA-RSP shall also include the SA-Descriptor for the service flow. If the corresponding 
DSA-REQ uses the Service Class Name (see 11.13.3) to request service addition, a DSA-RSP shall contain 
the QoS Parameter Set associated with the named Service Class. If the Service Class Name is used in 
conjunction with other QoS Parameters in the DSA-REQ, the BS shall accept or reject the DSA-REQ using 
the explicit QoS Parameters in the DSA-REQ. If these service flow encodings conflict with the Service 
Class attributes, the BS shall use the DSA-REQ values as overrides for those of the Service Class. 

If the transaction is unsuccessful, the BS shall use the original service flow reference to identify the failed 
parameters in the DSA-RSP. 

6.3.2.3.11.2 BS-lnitiated DSA 

If the transaction is unsuccessful, the SS shall use the SFID to identify the failed parameters in the DSA- 
RSP. 

6.3.2.3.12 DSA-ACK message 

A DSA-ACK shall be generated in response to a received DSA-RSP. The format of a DSA-ACK shall be as 
shown in Table 40. 



Table 40 — DSA-ACK message format 



Syntax 


Size 


Notes 


DSA-ACK_Message_Format() { 






Management Message Type = 13 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







Parameters shall be as follows: 

CID ( in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Transaction ID from corresponding DSA-RSP. 
Confirmation Code (see 11.13) 

The appropriate CC for the entire corresponding DSA-RSP. 
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All other parameters are coded TLV tuples. 
Service Flow Error Set (see 11.13) 

The Service Flow Error Set of the DSA-ACK message encodes specifics of any failed service flows 
in the DS A-RSP message. A Service Flow Error Set and identifying service flow reference shall be 
included for every failed QoS Parameter of every failed service flow in the corresponding DSA- 
REQ message (see 11.13). This parameter shall be omitted if the entire DSA-REQ is successful. 
HMAC T\iple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 

6.3.2.3.13 DSC Request (DSC-REQ) message 

A DSC-REQ is sent by an SS or BS to dynamically change the parameters of an existing service flow. 

An SS or BS shall generate DSC-REQ messages in the form shown in Table 41, including the following 
parameters: 

CD) ( in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Unique identifier for this transaction assigned by the sender. 
All other parameters are coded as TLV tuples. 



Table 41— DSC-REQ message format 



Syntax 


Size 


Notes 


DSC-REQ_Message_FormatO { 






Management Message Type = 14 


8 bits 




Transaction ID 


16 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







A DSC-REQ message shall not carry parameters for more than one service flow. 
A DSC-REQ shall contain the following: 

Service Flow Parameters (see 11.13) 

Specifies the service flow's new traffic characteristics and scheduling requirements. The Admitted 
and Active QoS Parameter Sets currently in use by the service flow. If the DSC message is success- 
ful and it contains service flow parameters, but does not contain replacement sets for both Admitted 
and Active QoS Parameter Sets, the omitted set(s) shall be set to null. The service flow parameters 
shall contain a SFID. 
HMAC Triple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 
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6.3.2.3.14 DSC Response (DSC-RSP) message 

A DSC-RSP shall be generated in response to a received DSC-REQ. The format of a DSC-RSP shall be as 
shown in Table 42. 



Table 42— DSC-RSP message format 



Syntax 


Size 


Notes 


DSC-RSP_Message_Format() { 






Management Message Type = 15 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




TLV Encoded Information 


variable 


TLV Specific 


} 







Parameters shall be as follows: 

CID ( in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Transaction ID from corresponding DSC-REQ. 
Confirmation Code (see 11.13) 
The appropriate CC for the corresponding DSC-REQ. 

All other parameters are coded as TLV tuples. 

If the transaction is successful, the DSC-RSP may contain the following: 
Service Flow Parameters (see 11.13) 

The complete specification of the service flow shall be included in the DSC-RSP only if it includes 
a newly assigned CID or an expanded Service Class Name. If a Service Flow Parameter Set 
contained an uplink Admitted QoS Parameter Set and this service flow does not have an associated 
CID, the DSC-RSP shall include a CID. If a Service Flow Parameter Set contained a Service Class 
Name and an Admitted QoS Parameter Set, the DSC-RSP shall include the QoS Parameter Set 
corresponding to the named Service Class. If specific QoS Parameters were also included in the 
Classed service flow request, these QoS Parameters shall be included in the DSC-RSP instead of 
any QoS Parameters of the same type of the named Service Class. 
CS Parameter Encodings (see 11.13.19) 
Specification of the service flow's CS specific parameters. 

If the transaction is unsuccessful, the DSC-RSP shall contain the following: 

Service Flow Error Set (see 11.13) 

A Service Flow Error Set and identifying CID shall be included for every failed service flow in the 
corresponding DSC-REQ message. Every Service Flow Error Set shall include every specific failed 
QoS Parameter of the corresponding service flow (see 1 1 . 1 3) . This parameter shall be omitted if the 
entire DSC-REQ is successful. 
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Whether successful or unsuccessful, the message shall include the following: 
HMAC Tuple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list). 

6.3.2.3.15 DSC Acknowledge (DSC-ACK) message 

A DSC-ACK shall be generated in response to a received DSC-RSP. The format of a DSC-ACK shall be as 
shown in Table 43. 



Table 43— DSC-ACK message format 



Syntax 


Size 


Notes 


DSC-ACK_Message_FormatO { 






Management Message Type = 16 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







Parameters shall be as follows: 

CID ( in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Transaction ID from the corresponding DSC-REQ. 
Confirmation Code (see 11.13) 

The appropriate CC for the entire corresponding DSC-RSP. 
All other parameters are coded TLV tuples. 
Service Flow Error Set (see 11.13) 

The Service Flow Error Set of the DSC-ACK message encodes specifics of any failed service flows 
in the DSC-RSP message. A Service Flow Error Set and identifying SFID shall be included for 
every failed QoS Parameter of each failed service flow in the corresponding DSC-RSP message 
(see 11.13). This parameter shall be omitted if the entire DSC-RSP is successful. 
HMAC Triple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 
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6.3.2.3.16 DSD-REQ message 

A DSD-REQ is sent by an SS or BS to delete an existing service flow. The format of a DSD-REQ shall be as 
shown in Table 44. 



Table 44— DSD-REQ message format 



Syntax 


Size 


Notes 


DSD-REQ_Message_Format() { 






Management Message Type = 17 


8 bits 




Transaction ID 


16 bits 




Service Flow ID 


32 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







Parameters shall be as follows: 

CID (in the generic MAC header) 

SS's Primary Management CID. 
Service Flow ID 

The SFID to be deleted. 
Transaction ID 

Unique identifier for this transaction assigned by the sender. 
All other parameters are coded as TLV tuples. 
HMAC Tuple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 
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6.3.2.3.17 DSD-RSP message 

A DSD-RSP shall be generated in response to a received DSD-REQ. The format of a DSD-RSP shall be as 
shown in Table 45. 



Table 45— DSD-RSP message format 



Syntax 


Size 


Notes 


DSD-RSPJvlessage_Format() { 






Management Message Type = 18 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




Service Flow ID 


32 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







Parameters shall be as follows: 

CD) (in the generic MAC header) 
SS's Primary Management CID. 
Service Flow ID 

SFID from the DSD-REQ to which this response refers. 
Transaction ID 

Transaction ID from the corresponding DSD-REQ. 
Confirmation Code (see 11.13) 
The appropriate CC for the corresponding DSD-REQ. 

All other parameters are coded as TLV tuples. 

HMAC T\iple (see 11.1.2) 

The HMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The 
HMAC Tuple attribute shall be the final attribute in the DSx message's attribute list. 
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6.3.2.3.18 Multicast Polling Assignment Request (MCA-REQ) message 

The MCA-REQ message is sent to an SS to assign it to or remove it from a multicast polling group. The 
format of the message is shown in Table 46. 



Table 46— MCA-REQ message format 



Syntax 


Size 


Notes 


MCA-REQ_Message_Format() { 






Management Message Type - 21 


8 bits 




Transaction ID 


16 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







Parameters shall be as follows: 

CID (in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Unique identifier for this transaction assigned by the sender. 

All other parameters are coded as TLV tuples. 

Multicast CID (see 11.10) 
Assignment (see 11.10) 

6.3.2.3.19 Multicast Polling Assignment Response (MCA-RSP) message 

The MCA-RSP is sent by the SS in response to a MCA-REQ. The message format shall be as shown in 
Table 47. 



Table 47— MCA-RSP message format 



Syntax 


Size 


Notes 


MCA-RSP_Message_FormatO { 






Management Message Type = 22 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




} 
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Parameters shall be as follows: 

CID (in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Unique identifier for this transaction assigned by the sender. 
Confirmation Code 

Zero indicates the request was successful. Non-zero indicates failure. 

6.3.2.3.20 Downlink Burst Profile Change Request (DBPC-REQ) message 

The DBPC-REQ message is sent by the SS to the BS on the SS's Basic CID to request a change of the down- 
link burst profile used by the BS to transport data to the SS. Note that a change of downlink burst profile 
may also be requested by means of a RNG-REQ message as defined in 6.3.2.3.5. 

The DBPC-REQ message shall be sent at the current operational Data Grant Burst Type for the SS. If the SS 
detects fading on the downlink, the SS uses this message to request transition to a more robust Data Grant 
Burst Type. The message format shall be as shown in Table 48. 



Table 48— DBPC-REQ message format 



Syntax 


Size 


Notes 


DBPC-REQ_Message_Format() { 






Management Message Type = 23 


8 bits 




reserved 


4 bits 


Shall be set to zero 


DIUC 


4 bits 




Configuration Change Count 


8 bits 




} 







Parameters shall be as follows: 
DIUC 

Data grant DIUC values. (PHY specific: SC— Table 145, SCa— Table 193, OFDM— Table 237, 
OFDMA— Table 276) 
Configuration Change Count 

Value of Configuration Change Count provided in DCD defining the burst profile associated with 
DIUC. 

6.3.2.3.21 Downlink Burst Profile Change Response (DBPC-RSP) message 

The DBPC-RSP message shall be transmitted by the BS on the SS's Basic CID in response to a DBPC-REQ 
message from the SS. If the DIUC parameter is the same as requested in the DBPC-REQ message, then the 
request was accepted. Otherwise, if the request is rejected, the DIUC parameter shall be the previous DIUC 
at which the SS was receiving downlink data. The message format shall be as shown in Table 49. 
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Table 49— DBPC-RSP message format 



kJJ 11 1<* A 


Size 


Notes 








Management Message Type = 24 


8 bits 




reserved 


4 bits 


Shall be set to zero 


DIUC 


4 bits 




Configuration Change Count 


8 bits 




} 







Parameters shall be as follows: 
DIUC 

Data grant DIUC values. (PHY specific: SC— Table 145, SCa— Table 193, OFDM— Table 237, 
OFDMA— Table 276) 
Configuration Change Count 

Value of Configuration Change Count provided in DCD defining the burst profile associated with 
DIUC. 

6.3.2.3.22 Reset Command (RES-CM D) message 

The RES-CMD message shall be transmitted by the BS on an SS's Basic CID to force the SS to reset itself, 
reinitialize its MAC, and repeat initial system access. This message may be used if an SS is unresponsive to 
the BS or if the BS detects continued abnormalities in the uplink transmission from the SS. 

The MAC Management Message Type for this message is given in Table 14. The RES-CMD message for- 
mat is shown in Table 50. 



Table 50— RES-CMD message format 



Syntax 


Size 


Notes 


RES-CMD_Message_Format() { 






Management Message Type = 25 


8 bits 




TLV encoded information 


variable 




} 







The RES-CMD shall include the following parameters encoded as TLV tuples: 
HMAC Tuple (see 11.1.2) 

The HMAC Tuple shall be the last attribute in the message. 
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6.3.2.3.23 SS Basic Capability Request (SBC-REQ) message 

The SS SBC-REQ shall be transmitted by the SS during initialization. An SS shall generate SBC-REQ 
messages in the form shown in Table 5 1 . 



Table 51— SS SBC-REQ message format 



Syntax 


Size 


Notes | 


SBC-REQ_Message_Format() • { 






Management Message Type = 26 


8 bits 




TLV Encoded Information 


variable 


TLV specific 


} 







An SS shall generate SS SBC-REQs including the following parameter: 
Basic CID (in the MAC Header) 

The CID in the MAC Header is the Basic CID for this SS, as assigned in the RNG-RSP message. 
All other parameters are coded as TLV tuples. 

Basic Capability Requests contain those SS Capabilities Encodings (11.7.8) that are necessary for effective 
communication with the SS during the remainder of the initialization protocols. Only the following 
parameters shall be included in the Basic Capabilities Request: 

Physical Parameters Supported (see 11.8.3) 
Bandwidth Allocation Support (see 11.8.1) 

6.3.2.3.24 SS Basic Capability Response (SBC-RSP) message 

The SS SBC-RSP shall be transmitted by the BS in response to a received SBC-REQ. 

To provide flexibility, the message parameters following the Response field shall be encoded in a TLV 
format. 



Table 52— SS SBC-RSP message format 



Syntax 


Size 


Notes 


SBC-RSP_Message_Format() { 






Management Message Type = 27 


8 bits 




TLV Encoded Attributes 


variable 


TLV specific 


} 
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A BS shall generate SS SBC-RSPs in the form shown in Table 52, including both of the following 
parameters: 

CID (in the MAC Header) 

The CID in the MAC Header is the Basic CID for this SS, as appears in the RNG-REQ message. 

The following parameters shall be included in the SBC-RSP if found in the SS SBC-REQ: 

Physical Parameters Supported (see 11.8.3) 
Bandwidth Allocation Support (see 11.8.1) 

The BS response to the subset of SS capabilities present in the SBC-REQ message. The BS 
responds to the SS capabilities to indicate whether they may be used. If the BS does not recognize 
an SS capability, it may return this as "off' in the SBC-RSP. 

Only capabilities set to "on" in the SBC-REQ may be set "on" in the SBC-RSP, as this is the 
handshake indicating that they have been successfully negotiated. 

6.3.2.3.25 Clock Comparison (CLK-CMP) message 

In network systems with service flows carrying information that requires the SSs to reconstruct their 
network clock signals (e.g., DS1 and DS3), CLK-CMP messages shall be periodically broadcast by the BS. 
When these services are not supported by the SS, the implementation of the CLK-CMP message at the SS 
shall be optional. If provisioned to do so, the BS shall take a clock difference measurement at every periodic 
interval (within the tolerance of the 10MHz reference defined in the definition of the Clock Comparison 
Value) defined in Table 342 and generate and transmit one CLK-CMP message according to the format 
shown in Table 53. 



Table 53— CLK-CMP message format 



Syntax 


Size 


Notes 


CLK-CMP JvIessage_Format() { 






Management Message Type = 28 


8 bits 




Clock Count n 


8 bits 




for (i = 1; i <-n\ i++) { 




For each clock signal 1 through n 


Clock ID[i] 


8 bits 




Sequence Number[i] 


8 bits 




Comparison Value[i] 


8 bits 




} 






} 







CLK-CMP messages shall include the following parameters where Clock ID, Sequence Number, and Clock 
Comparison Value (CCV) shall be repeated for each clock signal: 



Clock Count 

This 8-bit value shall be the number of CCVs included in the CLK-CMP message. 
Clock ID 

This 8-bit value shall be the unique identifier for each clock signal from which the CCVs are gener- 
ated by the BS. 
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Sequence Number 

This 8-bit value shall be incremented by one (modulo the field size, 256) by the BS whenever a 
new CLK-CMP message is generated. This parameter is used to detect packet losses. 
Clock Comparison Value 

This 8-bit value shall be the difference (modulo the field size, 256) between the following two 
reference clock signals: (1) a 10 MHz reference clock locked to the symbol clock of the airlink 
[such as a global positioning satellite (GPS) reference used to generate the symbol clock], and 
(2) an 8.192 MHz reference clock locked to the network clock. 

6.3.2.3.26 De/Re-register Command (DREG-CM D) message 

The DREG-CMD message shall be transmitted by the BS on an SS's Basic CID to force the SS to change its 
access state. The BS may transmit the DREG-CMD unsolicited or in response to an SS DREG-REQ mes- 
sage. Upon receiving a DREG-CMD, the SS shall take the action indicated by the action code. 

The MAC Management Message Type for this message is given in Table 14. The format of the message is 
shown in Table 54. 



Table 54— DREG-CMD message format 



Syntax 


Size 


Notes 


DREG-CMD_Message_Format() { 






Management Message Type = 29 


8 bits 




Action Code 


8 bits 




TLV encoded parameters 


variable 




} 







The Action Code values and the corresponding actions are specified in Table 55. 



Table 55— Action Codes and actions 



Action Code 


Action 


0x00 


SS shall leave the current channel and attempt to access another 
channel. 


0x01 


SS shall listen to the current channel but shall not transmit until an 
RES -CM D message or DREG_CMD with an Action Code that 
allows transmission is received. 


0x02 


SS shall listen to the current channel but only transmit on the Basic, 
Primary Management, and Secondary Management Connections. 


0x03 


SS shall return to normal operation and may transmit on any of its 
active connections. 


0x04 


SS shall terminate current Normal Operations with the BS; the BS shall 
transmit this action code only in response to any SS DREG-REQ 
message. 


0x05-0xFF 


reserved 
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The DREG-CMD shall include the following parameters encoded as TLV tuples: 
HMAC Tuple (see 11.1.2) 

The HMAC Tuple shall be the last attribute in the message. 
6.3.2.3.27 DSx Received (DSX-RVD) message 

The DSX-RVD message shall be generated by the BS in response to an SS-initiated DSx-REQ to inform the 
SS that the BS has received the DSx-REQ message in a more timely manner than provided by the DSx-RSP 
message, which shall be transmitted only after the DSx-REQ is authenticated. The format of the DSX-RVD 
shall be as shown in Table 56. 



Table 56— DSX-RVD message format 



Syntax 


Size 


Notes 


DSX-RVD_Message_Format() { 






Management Message Type = 30 


8 bits 




Transaction ID 


16 bits 




Confirmation Code 


8 bits 




} 







Parameters shall be as follows: 

CID (in the generic MAC header) 
SS's Primary Management CID. 
Transaction ID 

Transaction ID from corresponding DSx-REQ. 
Confirmation Code (see 11.13) 

The appropriate CC indicating the integrity of the corresponding DSx-REQ. 
6.3.2.3.28 Config File TFTP Complete (TFTP-CPLT) message 

The Config File TFTP-CPLT message shall be generated by the SS when it has successfully retrieved its 
configuration file from the provisioning server (see 6.3.9.12). If the SS does not need a config file it shall 
send the TFTP-CPLT message to the BS anyway, to indicate that it has completed secondary management 
connection initialization and is ready to accept services. The format of the TFTP-CPLT shall be as shown in 
Table 57. 



Table 57— TFTP-CPLT message format 



Syntax 


Size 


Notes 


TFTP-CPLT_Message_Format() { 






Management Message Type = 31 


8 bits 




TLV encoded information 


variable 




} 
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Parameters shall be as follows: 

CD) (in the generic MAC header) 
SS's Primary Management CID. 

The TFTP-CPLT shall include the following parameters encoded as TLV tuples: 

HMAC Tuple (see 11.1.2) 

The HMAC Tuple shall be the last attribute in the message. 
6.3.2.3.29 Config File TFTP Complete Response (TFTP-RSP) message 

The Config File TFTP-RSP message shall be generated by the BS in response to a TFTP-CPLT message 
from the SS (see 6.3.9.12). The format of the TFTP-RSP shall be as shown in Table 58. 



Table 58— Config File TFTP-RSP message format 



Syntax 


Size 


Notes 


TFTP-RSP_Message_Format() { 






Management Message Type = 32 


8 bits 




Response 


8 bits 




) 







Parameters shall be as follows: 

CD) ( in the generic MAC header) 
SS's Primary Management CID. 
Response 

A 1 byte quantity with one of the two values: 

0 = OK 

1 = Message authentication failure . 
6.3.2.3.30 ARQ Feedback message 

A system supporting ARQ shall be able to receive and process the ARQ Feedback message. 

The ARQ Feedback message, as shown in Table 59, can be used to signal any combination of different ARQ 
ACKs (cumulative, selective, selective with cumulative). The message shall be sent on the appropriate basic 
management connection. 



Table 59— ARQ Feedback message format 



Syntax 


Size 


Notes 


ARQ_Feedback_Message_Format() { 
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Table 59— ARQ Feedback message format (continued) 



Syntax 


Size 


Notes 


Management Message Type =33 


8 bits 




ARQ_Feedback_Payload 


variable 


See 6.3.3.4.3. 


} 







ARQ_Feedback_Payload field shall be either sent using this ARQ Feedback message or by packing ("piggy- 
backing") the ARCLFeedbackJayload as described in 6.3.3.4.3. 

6.3.2.3.31 ARQ Discard message 

This message is applicable to ARQ-enabled connections only. 

The transmitter sends this message when it wants to skip a certain number of ARQ blocks. The ARQ Dis- 
card message shall be sent as a MAC management message on the basic management connection of the 
appropriate direction. Table 60 shows the format of the Discard message. 



Table 60— ARQ Discard message format 



Syntax 


Size 


Notes 


ARQ_Discard_Message_Format() { 






Management Message Type = 34 


8 bits 




Connection ID 


16 bits 


CID to which this message refers. 


reserved 


5 bits 


Shall be set to zero. 


BSN 


11 bits 


Sequence number of the last block 
in the transmission window that the 
transmitter wants to discard. 


} 







6.3.2.3.32 ARQ Reset message 

This message is applicable to ARQ-enabled connections only. 

The transmitter or the receiver may send this message. The message is used in a dialog to reset the parent 
connection's ARQ transmitter and receiver state machines. The ARQ Reset message shall be sent as a MAC 
management message on the basic management connection of the appropriate direction. Table 61 shows the 
format of the Reset message. 
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Table 61— ARQ Reset message format 



Syntax 


Size 


Notes 


ARQ_Reset_Message_FormatO { 






Management Message Type = 35 


8 bits 




Connection ID 


16 bits 


CID for which this message refers to. 


Type 


2 bits 


00 = Original message from Initiator 

01 = Acknowledgment from Responder 

10 = Confirmation from Initiator 

11 = Reserved 


reserved 


6 bits 


Shall be set to zero. 


} 




» 



6.3.2.3.33 Channel measurement Report Request/Response (REP-REQ/RSP) 

If the BS, operating in bands below 11 GHz or a DM-configured BS operating at any frequency, requires 
RSSI and CINR channel measurement reports, it shall send the channel measurements Report Request 
message. In license-exempt bands, it shall additionally be used to request the results of the DFS 
measurements the BS has previously scheduled. Table 62 shows the REP-REQ meassage. 



Table 62— Channel measurements Report Request (REP-REQ) message format 



Syntax 


Size 


Notes 


Report_Request_Message_Format() { 






Management Message Type = 36 


8 bits 




Report Request TLVs 


variable 




} 







The REP-REQ message shall contain the following TLV encoded parameters: 
Report Request 

The channel measurement Report Response message shall be used by the SS to respond to the channel 
measurements listed in the received Report Requests. In license-exempt bands, the SS shall also send a REP- 
RSP in an unsolicited fashion upon detecting a Primary User on the channel it is operating in. The SS may 
also send a REP-RSP containing channel measurement reports, in an unsolicited fashion, or when non- 
primary user interference is detected above a threshold value. Table 63 shows the REP-RSP message. 
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Table 63— Channel measurement Report Response (REP-RSP) message format 



Syntax 


Size 


Notes 


Report_Response_Message_Format { 






Management Message Type = 37 


8 bits 




Report Response TLVs 


variable 




} 







The REP-RSP shall contain the following TLV encoded parameters: 
Report 

Compound TLV that shall contain the measurement Report in accordance with the Report Request 
(see 11.11). 

6.3.2.3.34 Fast Power Control (FPC) message 

Power control shall be effected by the use of periodic ranging. In addition, the BS may adjust the power 
levels of multiple subscribers simultaneously with the Fast Power Control (FPC) message. SSs shall apply 
the indicated change within the "SS downlink management message processing time." FPC shall be sent on 
the broadcast CID. This message shall only apply to SCa, OFDM, and OFDMA PHY specifications. See 
Table 64. 



Table 64— Fast power control message format 



Syntax 


Size 


Notes 


Fast_Power_Control message format () { 






Management message type = 38 


8 bits 




Number of stations 


8 bits 




for (i=0;i<Number of stations;i++) { 






Basic CID 


16 bits 




Power adjust 


8 bits 




} 






} 







Number of stations 

Number of CID and Power Adjust tuples contained in this message. 
Basic CID 

Basic connection identifier associated with the SS. 
Power Adjust 

Signed integer, which expresses the change in power level (in multiples of 0.25 dB) that the SS 
shall apply to its current transmission power. 
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6.3.2.3.35 MSH-NCFG message 

MSH-NCFG messages provide a basic level of communication between nodes in different nearby networks 
whether from the same or different equipment vendors or wireless operators. All the nodes (BS and SS) in 
the Mesh network shall transmit MSH-NCFGs as described in 6.3.7.5.5. 

All the nodes shall generate MSH-NCFGs in the format shown in Table 65, including all of the following 
parameters: 



Table 65 — MSH-NCFG message format 



Syntax 


Size 


Notes 


MSH-NCFG_Message_Format() { 






Management Message Type = 39 


8 bits 




NumNbrEntries 


5 bits 




NumBSEntries 


2 bits 




Embedded Packet Flag 


lbit 


0 = Not present, 1= present ( 


Xmt Power 


4 bits 




Xmt Antenna 


3 bits 




NetEntry MAC Address Flag 


lbit 


0= Not present, 1= present 


! Network base channel 


4 bits 




reserved 


4 bits 


Shall be set to zero 


NetConfig Count 


4 bits 




Timestamp 

Frame Number 

Network Control Slot Number in frame 
Synchronization Hop Count 


12 bits 
4 bits 
8 bits 


See 8.2.3.2 


NetConfig schedule info 

Next Xmt Mx 

Xmt Holdoff Exponent 


3 bits 
5 bits 




if (NetEntry MAC Address Flag) 
NetEntry MAC Address 


48 bits 




for (i=0; i< NumBSEntries; ++i) { 






BS Node ID 


16 bits 




Number of hops 


3 bits 




Xmt energy/bit 


5 bits 




} 






for (i=0; i< NumNbrEntries; ++i) { 






NbrNodelD 


16 bits . 




MSH-Nbr_Physical_IE() 


16 bits 


See Table 66 


if (Logical Link Info Present Flag) 
MSH-Nbr_LogicaI_IE() 


16 bits 


See Table 66 
See Table 67 



Copyright ©2004 IEEE. All rights reserved. 



81 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 1 6: 



Table 65— MSH-NCFG message format (continued) 



Syntax 


Size 


Notes 


} 






if (Embedded Packet Flag) 

MSH-NCFG„embedded_dataO 


variable 


See Table 68 


} 







NumNbrEntries 

Number of neighbors reported on in the message. The number of neighbors reported on may be a 
fraction of the whole set of neighbors known to this node. A node can report on subsequent subsets 
of neighbors in its subsequent MSH-NCFG transmissions. 

The following procedure is used to select the list neighbors of which only the Physical IE is 
reported: 

i) All neighbor entries with the "Reported Flag" set to TRUE are excluded as defined below 
in this subclause. 

ii) The remaining neighbor entries are ordered by the Next Xmt Time and those with the Next 
Xmt Time the furthest in the future are reported in this MSH-NCFG packet. (In general, 
learning of nodes with Next Xmt Times furthest into the future is more valuable than 
learning of nodes with Next Xmt Times approaching soon, since the neighbors will have 
more time to use this ineligibility information before it is stale.) 

The "Reported Flag" for all neighbors in either of the above neighbor lists is set to TRUE upon 
transmission of this MSH-NCFG packet. It is set to FALSE as described in 6.3.7.5.5.8. 
N270umBSEntries 

Number of Mesh BS neighbors reported on in this message. 
Xmt Power 

In 2 dBm steps, starting from 8 dBm. (i.e., 1111 indicates 38 dBm). 
Xmt Antenna 

The logical antenna used for transmission of this message. This allows for support for up to eight 
antenna directions. 
Network base channel 

The base channel being used in this node's network, which is the logical number of the physical 
channel (see 8.5.1), shall be used to broadcast schedule control information. A subset of the possi- 
ble physical channel numbers is mapped to logical channels in the Network Descriptor. 
Netconfig count 

Counter of MSH-NCFG packets transmitted by this node. Used by neighbors to detect missed 
transmissions. Incremented by 1 for every MSH-NCFG transmission by this node. 
Frame Number 

A modulo 2 12 number, which shall be increased by one for every frame. 
Network Control Slot Number in frame 

See 8.3.5.3. 

Synchronization hop count 

This counter is used to determine superiority between nodes when synchronizing the network. 
Nodes can be assigned as master time keepers, which are synchronized externally (for example 
using GPS). These nodes transmit a Synchronization hop count of 0. Nodes shall synchronize to 
nodes with lower synchronization hop count, or if counts are the same, to the node with the lower 
Node ID. 

Netconfig schedule info 
See Xmt Holdoff Exponent and Next Xmt Mx. 
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Xmt Holdoff Exponent 

The Xmt Holdoff Time is the number of MSH-NCFG transmit opportunities after Next Xmt Time 
(there are MSH-CTRL-LEN - 1 opportunities per network control subframe, see 8.3.53), that this 
. node is not eligible not transmit MSH-NCFG packets (see 6.3.7.5.5.6). 

Xmt Holdoff Time = 2 (Xmt Holdoff Ex P°nent + 4) (1) 
Next Xmt Mx 

Next Xmt Time is the next MSH-NCFG eligibility interval for this neighbor and computed as the 
range: 

2 Xmt Holdoff Exponent ^ ^ ^ < ^ ^ ^ < 2 X m t Holdoff Exponent ^ ^ ^ + J) (2) 

For example, if Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be consid- 
ered eligible for its next MSH-NCFG transmission between 49 and 64 (due to the granularity) 
transmission opportunities away and ineligible before that time. 

If the Next Xmt Mx field is set to Ox IF (all ones), then the neighbor should be considered to be 
eligible to transmit from the time indicated by this value and every MSH-NCFG opportunity there- 
after (i.e., treat Xmt Holdoff Time = 0). 

NetEntry MAC Address 

Indicates presence or sponsorship of new node. See Mesh Network Entry (MSH-NENT) message 
in 6.3.2.3.36 and Mesh network entry in 6.3.7.5.5.4. 
BS node ID 

Node ID of the Mesh BS node reported on. 
Number of hops 

Number of hops between the reporting node and the reported Mesh BS node. 
Xmt energy/bit factor 

Indication of energy^it needed to reach Mesh BS through this node. Xmt energy/bit is computed 
as in Equation (3). 



min 



where 

Wis the set of neighbors reporting the Mesh BS and E^j = P Tx /R.^. , 
P Tx is the transmission power in mW from node i to node j, 

Ri_>j is the datarate in Mb/s from node i to node / Ej is the Xmt energy/bit reported by neighbor / 
The reported Xmt energy/bit factor is the computed Xmt energy/bit divided by 

2(XmtEnergyUnitExponent - 4) r j 

XmtEnergyUnitExponent is a 4-bit field reported in the Network Descriptor. 
Nbr node ID 

Node ID of the neighbor node reported on. 
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6.3.2.3.35.1 Nbr Physical IE 



Table 66— Nbr Physical IE 



Syntax 


Size 


Notes 


MSH-NbrJPhysical_IE() { 






Logical Link Info Present 


lbit 


0 = Not present, 1 = present 


Logical Link Requested 


1 bit 


0 = No, 1 = Yes 


Logical Link Accepted 


lbit 


0 = No, 1 = Yes 


Hops to Neighbor 


lbit 


0 = 1 hop (direct neighbor), 1 = 2 hops 


Estimated propagation delay 


4 bits 


in jxs 


Nbr Next Xmt Mx 


5 bits ' 




Nbr Xmt Holdoff Exponent 


3 bits 




} 







6.3.2.3.35.2 Nbr Logical IE 

Table 67— Nbr Logical IE 



Syntax 


Size 


Notes 


MSH-Nbr_Logical_IE() { 






Rev Link Quality 


3 bit 




Nbr burst Profile 


4 bit 


Burst profile Nbr shall use in next 
transmission to this node 


Excess Traffic Demand 


lbit 


0 = No, 1 = Yes 


Nbr Xmt Power 


4 bits 




Nbr Xmt Antenna 


3 bits 




Short Preamble flag 


lbit 


0 = Don't use, 1 = Use Requested/Use 
Confirmed 


} 







Rev Link Quality 

Measure of the receive link reliability, indicating the reliability of MSH-NCFG size packets using 
the indicated burst profile. This is an estimated measure. 

The reliability is indicated in Equation (4): 

Reliability = 100(1- 10 "< RcvUnk ^ +1 > /4 ) % (4) 



84 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



Nbr burst profile 

Indicates the burst profile the indicated node should use when sending data bursts to the reporting 
node. 

Excess traffic demand 

May be used to indicate to the neighbor that the current schedule is insufficient to transfer pending 
traffic. 

Nbr Xmt Power 

The suggested transmit power for this neighbor to use for this link in 2 dBm steps, starting from 8 
dBm. (i.e., 1111 indicates 38 dBm). 
Short Preamble flag 

A node may optionally set this bit to notify the neighbor to use the short preamble (see 8.3.3.6) for 
transmissions in the data portion of the frame. Capability to transmit the short preamble is 
mandatory. Capability to receive the short preamble is optional. 

6.3.2.3.35.3 MSH-NCFG embedded data 



Table 68— MSH-NCFG embedded data 



Syntax 


Size 


Notes 


MSH-NCFG_embedded_data() { 






Extended embedded_data 


1 bit 


Indicates whether this embedded IE is 
followed by another one. 
0 = No, 1 = Yes 


reserved 


3 bits 


Shall be set to zero 


Type 


4 bits 




Length 


8 bits 


Length of embedded_IE in bytes, exclusive 
this header 


Embedded _data_IE() 


variable 


Type dependent 


} 







Type 

The following types are defined: 
0x0: Reserved 
0x1: Network Descriptor 
0x2: Network Entry Open 
0x3: Network Entry Reject 

0x4: Network Entry Ack (Embedded _data_IE() == NULL) 
0x5: Neighbor Link Establishment Protocol 
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The Network Descriptor shall contain the parameters listed in Table 69: 



Table 69— Network Descriptor IE 



Syntax 


Size 


Notes 


MSH-NCFG_embedded_data_IE() { 






Frame Length Code 


4 bits 


4 LSB of Frame Duration Code. See Table 232. 


MSH-CTRL-LEN 


4 bits 


Control subframe length (see 8.3.5.3). 


MSH-DSCH-NUM 


4 bits 


Number of DSCH opportunities in schedule control 
subframe (see 8.3.5.3). 


MSH-CSCH-DATA-FRACTION 


4 bits 




Scheduling Frames 


4 bits 


Defines how many frames have a schedule control 
subframe between two frames with network control 
subframes (see 8.3.5.3) in multiples of four frames, 
u — u irames, 
1=4 frames etc. 


Num_Burst_Profiles 


4 bits 


Number or burst proiiie aetinitions. n not set to 
zero, shall total all defined burst profiles. 


Operator ID 


lo bits 


. 


XmtEnergyUnitsExponent 


4 bits 




i Channels 


4 bits 


Number of logical channels. A value of 0 indicates 
the channel information is not carried in this 
message. 


MinCSForwardingDelay 


7 bits 


Number of OFDM symbols delay inserted between 
receiving and forwarding control packets. 


ExtendedNeighborhoodType 


lbit 


0 = 2-hop neighborhood 

1 = 3-hop neighborhood 


if (Channels) 

MSH-NCFG_Channel_IEO 


variable 




for (i=0;i < Num_Burst_Profiles;i++) { 






FEC Code Type 


8 bits 


See Table 362. 


Mandatory Exit Threshold 


8 bits 


See Table 362. 


Mandatory Entry Threshold 


8 bits 


See Table 362. 


j ) 






} 







MSH-CSCH-DATA-FRACTION 

Maximum percentage (value x 6.67) of minislots in the data-subframe allocated to centralized 
scheduling. The number of minislots is rounded to the nearest whole number of minislots and 
allocated starting from the beginning of the data subframe. The remainder of the data subframe, as 
well as any minislots not occupied by the current centralized schedule, may be used for distributed 
scheduling. 
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ExtendedNeighborhoodType 

If value 0, then only nodes with Hops to Neighbor = 0 (see 6.3.2.3.35.1) are reported; if value 1, 
then also nodes with Hops to Neighbor = 1 are reported. 
MinCSForwardingDelay 

The minimum delay in OFDM symbols that shall be inserted between the end of reception and the 
start of transmission of a centralized scheduling message (i.e., MSH-CSCH and MSH-CSCF) by 
any node. See Table 70 and Table 7 1 . 



Table 70— MSH-NCFG Channel IE (license-exempt) 



Syntax 


Size 


Notes 


MSH-NCFG_ChanneUE() { 




For license-exempt channels. ; 


for (i=0; i< Channels; ++i) 






Physical Channel code 


8 bits 


Physical channel (see 8.5.1) the logical channel i" is 
mapped to. Ordered with channels with same 
regulatory rules successive. 


Channel reuse 


3 bits 


Minimum number of hops of separation between links, 
before a channel can be reused by the centralized 
scheduling algorithm. Range is 1 hop to 7 hops, 0 for 
no reuse. 


Peak/Average flag 


lbit 


Regulatory limits are peak or average. 


reserved 


2 bits 


Shall be set to zero. 


NumChannelMaps 


2 bits 




for (i=0; i< NumChannelMaps; ++i) { 






Number of Channels 


8 bits 


Nodes in channel map to which rules apply. 


Max. xmt power at antenna port 


6 bits 


Regulatory limit in dBm. 


Max. EIRP 


6 bits 


Regulatory limit in dBm. 


} 






} 







Table 71— MSH-NCFG Channel IE (licensed) 



Syntax 


Size 


Notes 


MSH-NCFG_Channel_IE0 { 




For licensed channels. 


for (i=0; i< Channels; ++i) { 






Physical Channel center 
frequency 


24 bits 


Positive integer in kHz. 


Physical Channel width 


8 bits 


Positive integer in 100 kHz. 


J 
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Table 71— MSH-NCFG Channel IE (licensed) (continued) 



Syntax 


Size 


Notes 


Channel Reuse 


3 bits 


Minimum number of hops of separation between links, 
before a channel can be reused by the centralized 
scheduling algorithm. Range is 1 hop to 7 hops, 0 for 
no reuse. 


reserved 


5 bits 


Shall be set to zero. 


} 







The Network Entry Open, which is used to respond to MSH-NENT request messages, shall contain the 
parameters listed in Table 72: 



Table 72— Network Entry Open IE 



Syntax 


Size 


Notes 


MSH-CNFG_embedded_data_IE() { 






Minislot Start 


8 bits 


Schedule start for upper layer network entry. 


Minislot Range 


8 bits 


Schedule range for upper layer network entry. 


Frame number 


12 bits 


Frame number this schedule becomes valid. 


Channel 


4 bits 


Logical channel for new node to Xmt in above 
Minislot Range. 


Schedule validity 


12 bits 


Validity of Schedule in frames. 


Channel 


4 bits 


Logical Rev channel for new node. 


Estimated Propagation Delay 


4 bits 


Measured in jxs. 


reserved 


4 bits 


Shall be set to zero. 


} 







The Network Entry Reject, which is used to reject MSH-NENT requests, shall contain the parameters listed 
in Table 73: 



Table 73— Network Entry Reject IE 



Syntax 


Size 


Notes 


MSH-NCFG_embedded_dataJEO { 






Rejection Code 


8 bits 




Rejection Reason 


160 bits 


ASCII string 


} 
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Rejection Code 

0x0: Operator Authentication Value Invalid 
0x1: Excess Propagation delay 
0x2: Select new sponsor 

Neighbor Link Establishment IE is given in Table 74. 



Table 74— Neighbor Link Establishment IE 



Syntax 


Size 


Notes 


MSH-NCFG_embedded_data_IE() { 






Action Code 


2 bits 


0x0 Challenge 

Ox 1 Challenge response 

0x2 Accept 

0x3 Reject 


reserved 


6 bits 


Shall be set to zero. 


if (Action Code == 0x0 or 0x1) 






Nbr Authentication value 


32 bits 




if (Action Code = 0x1 or 0x2) 






Link ID 


8 bits 


Transmitting node's link ID for this link. 


} 







Nbr Authentication value 

HMAC{AK | frame number | own Node ID, Node ID of other node} where the AK is a secret key 
(obtained from Operator). 

6.3.2.3.36 MSH-NENT message 

MSH-NENT messages provide the means for a new node to gain synchronization and initial network entry 
into a Mesh network. 

When a MSH-NENT message is sent, the Mesh subheader is set to 0x0000 until the node has been assigned 
a node ID. In the Mesh CID, the Network ID is set the sponsor's network code or to 0x0000 if not known 
and the Link ID is set to OxFF (Broadcast). See Table 75. 



Table 75— MSH-NENT message format 



Syntax 


Size 


Notes 


MSH-NENT_Message_Format() { 






Management Message Type = 40 


8 bits 




Type 


3 bits 


0x0 Reserved 
0x1 NetEntryAck 
0x2 NetEntryRequest 
0x3 NetEntryClose 



Copyright ©2004 IEEE. All rights reserved. 



89 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



Table 75— MSH-NENT message format (continued) 



Syntax 


Size 


Notes 


Xmt counter for this Type 


3 bits 


For NetEntryAck, 
this is the Type being 
acknowledged. 


reserved 


2 bits 


Shall be set to zero. 


Sponsor Node ID 


16 bits 




Xmt Power 


4 bits 




Xmt Antenna 


3 bits 




reserved 


lbit 


Shall be set to zero. 


if (Type == 0x2) 






MSH-NENT_Request_IE() 


variable 




} 







Sponsor Node ID 

ID of the node sought to assist the requesting node in entering the network. 
Xmt Power 

In 2 dBm steps, starting from 8 dBm. (i.e., OxF indicates 38 dBm). 
Xmt Antenna 

The logical antenna used for transmission of this message. This allows for support for up to eight 
antenna directions. 

The MSH-NENT_request_IE is given in Table 76. 



Table 76— MSH-NENT Request IE 



Syntax 


Size 


Notes 


MSH-NENT_Request_IE() { 






MAC Address 


48 bits 




OpConflnfo 


64 bits 




Operator Authentication Value 


32 bits 




Node serial Number 


32 bits 




} 







MAC Address 

MAC Address of the new node sending the request. 
OpConflnfo 

Operator Configuration Information (obtained from Operator). 
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Operator Authentication Value 

HMAC{MAC Address | Node Serial Number | AK} 

where the AK is a secret key (obtained from Operator). 
6.3.2.3.37 MSH-DSCH message 

MSH-DSCH messages shall be transmitted in Mesh mode when using distributed scheduling. In coordinated 
distributed scheduling, all the nodes shall transmit a MSH-DSCH at a regular interval to inform all the 
neighbors of the schedule of the transmitting station. This transmission time is determined by the same algo- 
rithm used for MSH-NCFG messages (see 6.3.7.5.5.6). In both coordinated and uncoordinated scheduling, 
MSH-DSCH messages shall be used to convey resource requests and grants to the neighbors. Further, the 
MSH-DSCH messages shall be used to convey information about free resources that the neighbors can issue 
grants in. This message shall not be fragmented. The MSH-DSCH message format is given in Table 77. 



Table 77— MSH-DSCH message format 



Syntax 


Size 




ivj3ii-iJo^n_jviessage_rorTnat(j ( 






ivianagemeni iviessage iype =*n 


o bits 




Coordination Flag 


l bit 




Grant/Request Flag 


lbit 




Sequence counter 


6 bits 




No. Requests 


4 bits 




No. Availabilities 


4 bits 




No. Grants 


6 bits 




reserved 


2 bits 


Shall be set to zero. 


if (Coordination Flag == 0) 






MSH-DSCH_Scheduling_IE() 


variable 




for (i=0; i< No_Requests; ++i) 






MSH-DSCH_Request_IE() 


16 bits 




for (i=0; i< No_Availabilities; ++i) 






MSH-DSCH_Availability_IEO 


32 bits 




for (i=0; i< No_Grants; ++i) 






MSH-DSCH_Grant_IE() 


40 bits 




} 







Coordination Flag 

0 = Coordinated 

1 = Uncoordinated 

Coordinated MSH-DSCH transmissions take place in the control subframe (see 8.3.5.3). 
Uncoordinated MSH-DSCH transmissions take place in the data subframe (see 8.3.5.3). Both the 
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cases require a threeway handshake (Request, Grant, and Grant confirmation) to establish a valid 
schedule. Uncoordinated scheduling may only take place in minislots that cause no interference 
with the coordinated schedule. 

Grant/Request Flag 

0 = Request message 

1 = Grant message (also used as Grant confirmation) 

The Request Type indicates that a new Request is made of one or more other nodes. The No. 
Requests shall be nonzero in this case. The message may also contain Availabilities and Grants. 

The Grant Type indicates that one or more Grants are given or confirmed. The No. Grants shall be 
nonzero in this case. The message may also contain Availabilities and Requests. Requests in this 
type of message indicate pending demand to the indicated node(s), but do not solicit a Grant from 
this node. 

This flag is always set to 0 for coordinated distributed scheduling. 
Sequence Counter 

Sequentially increased counter for solicit messages in uncoordinated scheduling (used as multiple 
solicits might be outstanding). In coordinated scheduling, it allows nodes to detect missed 
scheduling messages. 

Independent counters are used for the coordinated and uncoordinated messages. 
No. Requests 

Number of Request IEs in the message. 
No. Availabilities 

Number of Availability IEs in the message. The Availability IEs are used to indicate free minislot 
ranges that neighbors could issue Grants in. 
No. Grants 

Number of Grant IEs in the message. 
6.3.2.3.37.1 MSH-DSCH Scheduling IE 

The Coordinated distributed scheduling information carried in the MSH-DSCH message shall be used to 
distribute information needed to determine transmission timing of the MSH-DSCH messages with 
coordinated distributed scheduling. Each node shall report the two related parameters both of its own and all 
its neighbors. The scheduling information shall include all of the following parameters: 

Next Xmt Mx 

Next Xmt Time is the next MSH-DSCH eligibility interval for this node and computed as the 
range: 

2 Xmt Holdoff Exponent # ^ ^ Mx < ^ ^ ^ < 2 Xmt Holdoff Exponent . ^ ^ Mx+ ^ (5) 

For example, if Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be 
considered eligible for its next MSH-DSCH transmission between 49 and 64 (due to the 
granularity) transmission opportunities away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbor should be considered to be 
eligible to transmit from the time indicated by this value and every MSH-DSCH opportunity there- 
after (i.e., treat Xmt Holdoff Time = 0). 
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Neighbor Next Xmt Mx 

Advertises the Next Xmt Mx as reported by this neighbor. 
Xmt Holdoff Exponent 

The Xmt Holdoff Time is the number of MSH-DSCH transmit opportunities after Next Xmt Time 
(there are MSH-CTRL-LEN -1 opportunities per network control subframe, see 8.3.5.3) that this 
node is not eligible to transmit MSH-DSCH packets (see 6.3.7.5.5.6). 

Xmt Holdofif Time = 2 (Xmt Holdoff Ex P° nent+ 4 ) (6) 
Neighbor Xmt Holdoff Exponent 

Advertises the Xmt Holdoff Exponent as reported by this neighbor. 
No. SchedEntries 

Number of Neighbor MSH-DSCH Scheduling Entries in the message. See Table 78. 
Neighbor Node ID 

The Node ID of the neighbor being reported on. 



Table 78— MSH-DSCH Scheduling IE 



Syntax 


Size 


Notes 


MSH-DSCH_SchedulingJEO { 






Next Xmt Mx 


5 bits 




Xmt holdoff exponent 


3 bits 




No. SchedEntries 


8 bits 




for (i=0; i< No_SchedEntries; ++i) { 






Neighbor Node ID 


16 bits 




Neighbor Next Xmt Mx 


5 bits 




Neighbor Xmt holdoff exponent 


3 bits 




} 






} 







6.3.2.3.37.2 MSH-DSCH Request IE 

The Requests carried in the MSH-DSCH message shall convey resource requests on per link basis. The 
Requests shall include all of the parameters listed in Table 79: 



Table 79— MSH-DSCH Request IE 



Syntax 


Size 


Notes 


MSH-DSCH_Request_IE0 { 






Link ID 


8 bits 




Demand Level 


8 bits 




Demand Persistence 


3 bits 




reserved 


1 bit 


Shall be set to zero. 


} 
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Link ID 

The ID assigned by the transmitting node to the link to this neighbor that this request involves: 
Demand Level 

Demand in minislots (assuming the current burst profile). 
Demand Persistence 

Persistency field for demands. Number of frames wherein the demand exists. 

0 = cancel reservation 

1 = single frame 

2 = 2 frames 

3 = 4 frames 

4 = 8 frames 

5 = 32 frames 

6 = 128 frames 

7 = Good until cancelled or reduced 
6.3.2.3.37.3 MSH-DSCH Availabilities IE 

The Availabilities carried in the MSH-DSCH message shall be used to indicate free minislot ranges that 
neighbors could issue Grants in. The Availabilities shall include all of the parameters listed in Table 80: 



Table 80— MSH-DSCH Availability IE 



Syntax 


Size 


Notes 


MSH-DSCH_Availability_IE() { 






Start Frame number 


8 bits 


8 LSB of Frame number. 


Minislot start 


8 bits 




Minislot range 


7 bits 




Direction 


2 bits 




Persistence 


3 bits 




Channel 


4 bits 




} 







Start Frame number 

Availability start: 

Indicates lowest 8 bits of frame number in which the availability starts. 
Minislot start 

The start position of the availability within a frame (minislots as time unit, see 8.3.5.3 for 
definition). 
Minislot range 

The number of minislots free for grants 
Direction 

0 = Minislot range is unavailable. 

1 = Available for transmission in this minislot range. 

2 = Available for reception in this minislot range. 

3 = Available for either transmission or reception 
Persistence 

Persistency field for Availabilities. Number of frames over which the Availability is valid. 
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0 = cancel availability 

1 = single frame 

2 = 2 frames 

3 = 4 frames 

4 = 8 frames 

5 = 32 frames 

6 = 128 frames 

7 = Good until cancelled or reduced 

Channel 

Logical channel number, which is the logical number of the physical channel. A subset of the 
possible physical channel numbers is mapped to logical channels in the Network Descriptor. 

6.3.2.3.37.4 MSH-DSCH Grants IE 

The Grants carried in the MSH-DSCH message shall convey information about a granted minislot range 
selected from the range reported as available. Grants shall be used both to grant and confirm a grant. The 
Grants shall include all of the parameters listed in Table 81 : 



Table 81— MSH-DSCH Grants IE 



Syntax 


Size 


Notes 


MSH-DSCH_Grants_IE() { 






Link ID 


8 bits 




Start Frame number 


8 bits 


8 LSB of Start Frame number. 


Minislot start 


8 bits 




Minislot range 


8 bits 




Direction 


lbit 




Persistence 


3 bits 




Channel 


4 bits 




} 







Link ID 

The ID assigned by the transmitting node to the neighbor that this grant involves. 
Start Frame number 
Schedule start: 

Indicates lowest 8 bits of frame number in which the schedule is granted. 
Minislot start 

The start position of the reservation within a frame (minislots as time unit, see 8.3.5.3 for 
definition). 
Minislot range 

The number of minislots reserved/ 
Direction 

0= From requester (i.e., to granter) 
1= To requester (i.e., from granter) 
Persistence 

Persistency field for grants. Number of frames over which the grant is allocated. 
0 = cancel reservation 
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1 = single frame 

2 = 2 frames 

3 = 4 frames 

4 = 8 frames 

5 = 32 frames 
6= 128 frames 

7 = Good until cancelled or reduced 

Channel 

Logical channel number, which is the logical number of the physical channel. A subset of the 
possible physical channel numbers is mapped to logical channels in the Network Descriptor. 

6.3.2.3.38 Mesh centralized scheduling (MSH-CSCH) message 

A MSH-CSCH message shall be created by a Mesh BS when using centralized scheduling. The BS shall 
broadcast the MSH-CSCH message to all its neighbors, and all the nodes with hop count lower than 
HRthreshold sha11 forward the MSH-CSCH message to their neighbors that have a higher hop count. In all 
these cases, the Grant/Request Flag = 0. HR thresho i d is a configuration value that need only be known to the 
Mesh BS, as it can be derived by the other nodes from the MSH-CSCF message. 

Nodes can use MSH-CSCH messages to request bandwidth from the Mesh BS setting the Grant/Request 
Flag = 1. Each node reports the individual traffic demand requests of each "child" node in its subtree from 
the BS. The nodes in the subtree are those in the current scheduling tree to and from the Mesh BS, known to 
all nodes in the network, and ordered by node ID. 

The BS shall generate MSH-CSCHs in the format shown in Table 82, including all of the following 
parameters: 

Configuration sequence number 

Indicates the configuration that shall be used to interpret this packet. It refers to the configuration 
number in the MSH-CSCF packet. 
Grant/Request Flag 

0 = Grant (transmitted in downlink) 

1 = Request (transmitted in uplink) 
Configuration Flag 

Indicates which centralized scheduling control message type (CSCH or CSCF) will be transmitted 
next by the Mesh BS. This bit may be set to aid the nodes in computing the validity of the schedule 
indicated in the current message (see 6.3.6.6.2). 
Flow Scale Exponent 

Determines scale of the granted bandwidth. Its value typically depends on the number of nodes in 
the network, the achievable PHY bit rate, the traffic demand, and the provided service. 

For the downlink, this gives the absolute values of flow granted, so the total minislot range allowed 
for centralized scheduling need not be used if not needed, with the remainder set aside for distrib- 
uted scheduling. 

For uplink, the lowest exponent possible is used at each hop, with quantization of forwarded 
requests rounded up (e.g., avoids reducing any requests to zero). 

Num_Link_updates 

Link updates are inserted by the Mesh BS if the number of link tree changes does not warrant a 
MSH-CSCF broadcast. The Mesh BS shall repeat the a link update in every MSH-CSCH either 
until the update becomes invalid, or until the change is reflected in a MSH-CSCF message. 
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NumFlowEntries 

Number of 8-bit assignment fields followed, ordered according to appearance in MSH-CSCR This 
number shall match the number of entries in the most recent MSH-CSCF message. 
UplinkFlow 

Base of the granted/requested bandwidth as bits/s for the uplink traffic of the node in the BS's 
scheduling tree. The allocation is the same as for DownlinkFlow. 
DownlinkFlow 

Parameter used, as shown in Equation (7), to compute the granted/requested bandwidth as bits/s for 
the downlink traffic of the node in the BS's scheduling tree. The flow indicates only traffic that 
initiates or terminates in the node itself (i.e., forwarded traffic is not included), except for traffic 
forwarded from/to nodes not part of the MSH-CSCF tree. The actual granted/requested bandwidth 
shall be calculated as 

™»m t0 BS = UplinkFlow • 2 FUwsca,e Exponen,+14 bits/s 

(7) 

BW^ ^ BS = DownlinkFlow • 2™ e ^ m+14 bits/s 

The assignments in the list are ordered according to the order in the MSH-CSCF message (see 
6.3.2.3.39). 

Frame schedule flag 

If this flag is set, the allocation of flows shall occur over two frames, rather than one. 
Sponsor Node Request 

Three parameters (Sponsor Node, and Downlink Burst Profile, and Uplink Burst Profile) shall be 
set to 0, except by nodes that wish to reserve an allocation for the "upper MAC initialization" as 
specified in 6.3.9.14.3. A node may only set these values if all its children report these values as 0. 
The Mesh BS shall in response provide a grant to Node Index 0x00, which shall be reserved for this 
purpose. 



Table 82— MSH-CSCH message format 



Syntax 


Size 


Notes 


MSH-CSCH_Message_Format() { 






Management Message Type = 42 


8 bits 




Configuration sequence number 


3 bits 


Last MSH-CSCF sequence number. 


Grant / Request Flag 


1 bit 


0 = Grant, 1 - Request. 


Frame schedule Flag 


Ibit 




Configuration Flag 


1 bit 


0 = Next schedule control message is MSH-CSCH. 

1 = Next schedule control message is MSH-CSCF. 


reserved 


2 bits 


Shall be set to zero. 


NumFlowEntries 


8 bits 




for (i=0; i< NumFlowEntries; ++i)*{ 






UplinkFlow 


4 bits 




if (Grant / Request Flag == 0) 
DownlinkFlow 


4 bits 




} 







Copyright ©2004 IEEE. All rights reserved. 



97 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



Table 82— MSH-CSCH message format (continued) 



Syntax 


Size 


Notes 


Flow Scale Exponent 


4 bits 




Padding Nibble 


4 bits 




if (Grant/Request Rag = =0) { 






No_link_updates 


4 bits 




for (i=0; i< No_link_updates; ++i) { 






Node Index self 


8 bits 


Index in MSH-CSCF list. 


Node Index parent 


8 bit 


Index in MSH-CSCF list. 


Uplink Burst Profile 


4 bit 




Downlink Burst Profile 


4 bit 




} 






} else { 




Sponsor Node Request. 


Sponsor Node 


8 bits 


Index in node tree. 


Downlink Burst Profile 


4 bits 




Uplink Burst Profile 


4 bits 




} 






} 







6.3.2.3.39 Mesh centralized scheduling Configuration (MSH-CSCF) message 

A MSH-CSCF message shall be broadcast in Mesh mode when using centralized scheduling. The Mesh BS 
shall broadcast the MSH-CSCF message to all its neighbors, and all nodes shall forward (rebroadcast) the 
message according to its index number specified in the message. The BS shall generate MSH-CSCFs in the 
format shown in Table 83. 



Table 83 — MSH-CSCF message format 



Syntax 


Size 


Nodes 


MSH-CSCF JMessage_Format() { 






Management Message Type = 43 


8 bits 




Configuration sequence number 


4 bits 




NumberOfChannels 


4 bits 




for (i=0; i< NumberOfChannels; ++i) { 






Channel index 


4 bits 




} 






Padding Nibble 


0 or 4 bits 


Pad till byte boundary. 
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Syntax 


Size 


Nodes 


NumberOfNodes 


8 bits 




for (i=0; i< NumberOfNodes; ++i) { 






NodelD 


16 bits 


Node index for this node is L 


NumOfChildren 


8 bits 




for (j=0; j< NumberOfChildren; ++j) { 






Child Index 


8 bits 


Index of / h child node. 


Uplink Burst Profile 


4 bits 


Burst profile from 7 th child node. 


Downlink Burst Profile 


4 bits 


Burst profile to / h child node. 


} 






} 






} 







Configuration sequence number 

Number of the configuration. With each new configuration message, the number is incremented by 
1. 

NumberOfChannels 

Number of channels available for centralized scheduling. 
Channel Index 

The logical index of the Physical channel, as reported in MSH-NCFG:NetworkDescriptor. 
NumberOfNodes 

Number of nodes in scheduling tree. 
Each entry of the scheduling tree shall include all of the following parameters: 
Node ID 

Unique node identifier assigned to node. 
NumberOfChildren 

Number of child nodes for this node. A child node is a neighbor with a hop count, which is one 
higher than this nodes hop count. 

Childlndex 

NumberOfChildren index in this table of child node. 
Uplink/Downlink Burst Profile 

Burst profile of link from/to child node. 
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6.3.2.3.40 AAS Channel Feedback Request/Response (AAS-FBCK-REQ/RSP) 

The AAS Channel Feedback Request message shall be used by a system supporting AAS. This message 
serves to request channel measurement that will help in adjusting the direction of the adaptive array. See 
Table 84. 

Table 84— AAS Feedback Request (AAS-FBCK-REQ) message format 



Syntax 


Size 


Nodes 


AAS-FBCK-REQ_Message_Format() { 






Management Message Type = 44 


8 bits 




Message body 


variable 


See 8.2, 8.3, or 8.4. 


} 







The AAS Channel Feedback Response message shall be sent as a response to the AAS-FBCK-REQ message 
after the indicated measurement period has expired. See Table 85. 

Table 85— AAS Feedback Response (AAS-FBCK-RSP) message format 



Syntax 


Size 


Nodes 


AAS-FBCK-RSP_Message_Format() { 






Management Message Type = 45 


8 bits 




Message body 


variable 


See 8.2, 8.3, or 8.4. 


} 







6.3.2.3.41 AAS Beam Select message 

The AAS Beam Select message may be used by a system supporting AAS. This message may be sent by the 
SS in an unsolicited manner, to inform the BS about the preferred beam for the AAS SS sending this 
message. The AAS Beam Select message shall be sent on the basic CID. 



Table 86— AAS_Beam_Select message format 



Syntax 


Size 


Notes 


AAS_Beam_Select message format() { 






Management message type = 46 


8 bits 




AAS beam index 


6 bits 




reserved 


2 bits 


Shall be set to zero. 


} 
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AAS beam index 

This index shall correspond to the direction the AAS beam is pointing at during the 
AAS_DL_Scan_IE() preferred by the SS (see 8.4.4.6). 

6.3.2.3.42 SS De-registration Request (DREG-REQ) message 

An SS may send a DREG-REQ message to a BS in order to notify the BS of SS de-registration from Normal 
Operation service from the BS. The MAC Management Message Type for this message is given in Table 14. 
The format of the message is shown in Table 87. 



Table 87— DREG-REQ message format 



Syntax 


Size 


Notes 


DREG-REQ message formatO { 






Management message type = 49 


8 bits 




De-registration_Request_Code 


8 bits 


0x00 = SS de-registration request from BS 
and network 
0x0\-0xFF = Reserved 


TLV encoded parameters 


variable 




} 







An SS shall generate SS DREG-REQs including the following parameters: 
De-registration_Request_Code 

Request code identifying the type of de-registration request: 
0x00 = SS de-registration request for de-registration from BS 
0x01 -0xFF = reserved 

The DREG-REQ shall include the following parameters encoded as TLV tuples: 

HMAC Triple (see 11.1.2) 

The HMAC Tuple shall be the last attribute in the message. 
6.3.2.3.43 H-ARQ MAP message 

This subclause describes the H-ARQ MAP message, which is designed for H-ARQ enabled SS. This IE 
shall only be used by a BS supporting H-ARQ, for SS supporting H-ARQ. 

6.3.2.3.43.1 H-ARQ MAP message format 

The H-ARQ MAP message format is presented in Table 88. This message includes Compact DL/UL- 
MAPJE and defines the access information for the downlink and uplink burst of H-ARQ enabled SS. This 
message shall be sent without a generic MAC header. 

BS may broadcast multiple H-ARQ MAP messages using multiple burst after the MAP message. Each H- 
ARQ MAP message should have a different modulation and coding rate. If the frame contains DCD or UCD 
message following the MAP message, the H-ARQ MAP should follow DCD or UCD message. 
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The DL-MAP_IEs in the MAP message describe the location and coding and modulation schemes of the 
bursts. The order of DLMAPJEs in the MAP message and the bursts for H-ARQ MAP messages is 
determined by the coding and modulation scheme of the burst. The burst for H-ARQ MAP message with 
lower rate coding and modulation should be placed before other bursts for H-ARQ MAP message. 

The presence of the H-ARQ MAP message format is indicated by the contents of the three most significant 
bits of the first data byte of a burst. These bytes overlay the HT and EC bits of a generic MAC header. When 
these bits are both set to 1 (an invalid combination for a standard header) and followed by 1 bits of 1, the 
Compact DL-MAP format is present. 



Table 88 — H-ARQ MAP message format 



Syntax 


Size 


Notes 


H-ARQ_MAP message format() { 






H-ARQ MAP Indicator = 111 


3 bits 


SettoOblll. 


H-ARQ_UL-MAP appended 


lbit 




| CRC appended 


lbit 




Map message length 


9 bits 


Length of H-ARQ MAP in bytes. 


DL IE count 


6 bits 


Number of DL IE in the burst. ! 


for (i=0; i < DL IE count; i++){ 






Compact DL-MAP IE() 


variable 




} 






If (Compact_UL-MAP appended ==1){ 






while (map data remains) { 






Compact DL-MAP IE() 


variable 




} 






} 






if !(byte boundary) { 






Padding nibble 


4 bits 




} 






} 







H-ARQ MAP Indicator 

The value of Obi 11 means this message is a H-ARQ MAP Message. 
Compact UL-MAP appended 

A value of 1 indicates a compact UL-MAP is appended to the current compact DL-MAP data 
structure. 
CRC appended 

A value of one indicates a CRC-32 value is appended to the end of the H-ARQ MAP data. The 
CRC is computed across all bytes of the H-ARQ MAP starting with the byte containing the H-ARQ 
MAP indicator through the last byte of the map as specified by the Map message length field. The 
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CRC calculation is the same as that used for standard MAC messages. A value of zero indicates 
that no CRC is appended. 
MAP message length 

This value specifies the length of the H-ARQ MAP message beginning with the byte containing the 
H-ARQ MAP indicator and ending with the last byte of the H-ARQ MAP message. The length 
includes the computed 32-bit CRC value if the CRC appended indicator is on. 
DL IE count 

This field holds the number of IE entries in the following list of DL-MAP IEs. 
Table 89 and Table 90 represent the types of compact DL/UL MAP IE. 



Table 89 — Compact_DL-MAP IE types 



Compact DL-MAP Type 


Description 


0 


Normal subchannel 


1 


Band AMC 


2 


Safety 


3 


DIUC 


4 


Format_Configuration_IE 


5 


H-ARQ_ACK_BITMAP_IE 


6 


reserved 


7 


Extension 


Table 90— Compact_UL-MAP IE types 


Compact UL-MAP Type 


Description 


0 


Normal subchannel 


1 


Band AMC 


2 | 


Safety 


3 


UIUC 


4 


H-ARQ_Region_IE 


5 


CQI_Region_IE 


6 


reserved 


7 


Extension 
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6.3.2.3.43.2 Format Configuration 

Table 91 represents the format of Format_Configuration_IE that configures CID type, safety pattern, 
maximum logical bands, and frame structure. The format should be set to default value at the start of each 
frame. 



Table 91— Format configuration IE 



Syntax 


Size 


Notes 


Compact_DL-MAP JE( ) { 






DL-MAP Type = 4 


3 bits 


Format_Confi guration JE 


New Format Indication 


1 kit 

1 Dlt 


u = use ine rormai coniigureu oy me ldicsi 

Format_Configuration_IE 
1 = New format 


if (New Format Indication == 1) { 






CD) Type 


2 bits 


00 = Normal CID 

Ui = KL-iDi i (Qeiaunj 

10 = RCID7 

11 =RCID3 


Safety Pattern 


10 bits 




Subchannel type for Band AMC 


2 bits 


See Band AMC specification (8.4.6.3). 

00 = Default type (default) 

01 = 1x6 type 

10 = 2x3 type 

11 = 3x2 type 


Max Logical Bands 


2 bits 


0 = 3 bands, 

1 = 6 bands, 

2 = 12 bands (default) 

3 = 24 bands 


No. Symbols for Broadcast 


4 bits 


No. Symbol, (default = 0) 


No. Symbols for DL Band AMC 


4 bits 


No. Symbol, (default = 0) 


No. Symbols for UL Band AMC 


4 bits 


No. Symbol, (default = 0) 


} 






} 







New Format Indication 

If this value set to 0, the format should be configured by the latest Format Configuration_IE in the 
previous frames. Otherwise, all parameters in Format Configuration IE should be configured. The 
configured parameters are valid for the following Compact_DL/UL_MAP_IE. At the start of each 
frame all parameters are set to default values. 
CID Type 

This value specifies CID type used in the Compact J)L/UL_MAP_IE. 
Safety Pattern 

If this value is less than 16, the number of safety bins is 12 and the indices of allocated bins for 
safety are 16m+x y where x is the value of Safety Pattern and m = 0 ... 11. If this value is not less 
than 16, the number of safety bins is 24 and the indices of allocated bins for safety are 16m+x' and 
16m+(x'+8), where x y = x - 16 and m = 0...11. 
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Subchannel Type for Band AMC 

This value specifies the subchannel type for Band AMC subchannel. See related PHY 
specification. 

No. Symbols for Broadcast 

This specifies the number of symbols allocated for Broadcast subchannel. 
No. Symbols for DL Band AMC 

This specifies the number of symbols allocated for DL Band AMC subchannel. The other DL 
symbols excluding the symbols for Broadcast and DL Band are allocated for the DL Normal 
subchannel. 

No. Symbols for UL Band AMC 

This specifies the number of symbols allocated for UL Band AMC subchannel. The other UL 
symbols excluding the symbols for UL Band are allocated for the UL Normal subchannel. 
Max Logical Bands 

This value specifies the maximum number of logical bands for Band AMC. The size of 3 fields 
(No. Selected Bands, Band BITMAP and Band Index) in the DL/UL-MAP_IE for Bands AMC 
depends on this value. Table 92 represents the fields in the DL/UL-MAPJE and specific values. 



Table 92— Field length for Band AMC MAPJE 



Logical Bands 


24 Bands 


12 Bands 


6 Bands 


3 Bands 


Max Logical Bands 


11 


10 


01 


00 


Nb-Band (# of bits for No. Selected Bands) 


4 bits 


4 bits 


4 bits 


Obits 


Nb-BITMAP (# of bits for Band BITMAP) 


24 bits 


12 bits 


8 bits 


4 bits 


Nb-Index (# of bits for Band Index) 


8 bits 


4 bits 


4 bits 


Obits 



6.3.2.3.43.3 Reduced CID 

Figure 93 presents the format of reduced CID. BS may use reduced CID instead of basic CID or multicast 
CID to reduce the size of HARQ MAP message. The type of reduced CID is determined by BS considering 
the range of basic CIDs of SS connected with the BS and specified by the RCID_Type field of the Format 
Configuration IE. 

The reduced CID is composed of 1 bit of prefix and n-bits of LSB of CID of SS . The prefix is set to 1 for the 
broadcast CID or multicast CID and set to 0 for basic CID. The reduced CID cannot be used instead of 
transport CID, primary management CID, or secondary management CID. 

Figure 22 shows the decoding of reduced CID when the RCID_Type is set to 3. 
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Prefix = 0, Basic CID 



RDC11 |~0~ 


1 


0 


1 


1 


0 


0 


1 


1 


1 


1 


0 






w 

\\ 
w 
\\ 
v\ 
w 


\ 

\ 

\ 

\ 

\ 

\ 

\ 

\ 


CID 0 


0 


0 


0 


1 


0 


1 


1 


0 


0 


1 


1 


1 1 0 J 



Prefix = 1, Multicast or Broadcast CID 



RDC11 



CID 



ECU 





1 


1 


0 


0 


1 


1 


1 


1 


0 



1 


1 


1 


1 


1 


0 


1 


1 


0 


0 


1 


1 


1 


1 


0 



Figure 22— Reduced CID Decoding 



Table 93— RCIDJE format 



Syntax 


Size 


Notes 


RCIDJE () { 






if(RCID_Type==0) { 




RCID_Type is specified in 
Format_Configuration IE 


CID 


16 bits 


Normal CID 


} else { 






Prefix 


1 bit 


For multicast, AAS, Padding and broadcast 
burst temporary disable RCID 


if (Prefix == 1){ 






RCID 11 


11 bits 


11 LSB of Multicast, AAS or Broadcast CID 


} else { 






if(RCIDJType == 1) { 






RCID 11 


11 bits 


11 LSB of Basic CID 


}else if(RCID_Type== 2) { 






RCID 7 


7 bits 


7 LSB of Basic CID 


j }elseif(RCID_Type==3){ 
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Table 93 — RCIDJE format (continued) 



Syntax 


Size 


Notes 


ROD 3 


3 bits 


3 LSB of Basic CID 


} 






} 






} 






} 







CID 

Normal 16 bits CID. 
Prefix 

A value of 1 indicates that 11 bits RCID for broadcast and multicast follows the prefix. Otherwise, 
the n-bits RCID for basic CID follows the prefix. The value of n is determined by the RCIDJType 
field in Format_Configuration_IE. 
RCID n 

n-bits LSB of CID. 
6.3.2.3.43.4 H-ARQ control IE 

The format of H-ARQ_Control_IE, which includes encoding/decoding information for H-ARQ enabled DL/ 
UL bursts, is presented in Table 94. This IE shall be located in the compact DL/UL MAP_IE. 



Table 94 — H-A RQ_Co nt ro I IE format 



Syntax 


Size 


Notes 


H-ARQ_Control_IE () 






Prefix 


1 bit 


0 = Temporary disable H-ARQ 

1 = enable H-ARQ 


if (Prefix == 1) { 






AI_SN 


lbit 


H-ARQ ID Seq. No 


SPID 


2 bits 


Subpacket ID 


ACID 


4 bits 


H-ARQ CH ID 


} else { 






reserved 


3 bits 


Shall be set to zero 


1 j 






} 







Prefix 

Indicates whether H-ARQ is enabled or not. 
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AI_SN 

Defines ARQ Identifier Sequence Number. This is toggled between "0" and "1" on successfully 
transmitting each encoder packet with the same ARQ channel. 
SPID 

Defines SubPacket ID, which is used to identify the four subpackets generated from an encoder 
packet. 
ACID 

Defines H-ARQ Channel ID, which is used to identify H-ARQ channels. Each connection can have 
multiple HARQ channels, each of which may have an encoder packet transaction pending. 

6.3.2.3.43.5 CQICH Control IE 

The format of CQICH Control IE is presented in Table 95. 



Table 95— H-ARQ_Control IE format 



Syntax 


Size 


Notes 


CQICH_Control_IE () { 






CQICH indicator 


lbit 


If the indicator is set to 1, the 
CQICH_Control IE follows. 


if (CQICH indicator == 1) { . 






Allocation Index 


6 bits 


Index to the channel in a frame the CQI 
report should be transmitted by the SS. 


Period (p) 


2 bits 


A CQI feedback is transmitted on the CQI 
channels indexed byW (CQI Channel 
Index) by the SS in every 2 P frames. 


Frame offset 


3 bits 


The MSS starts reporting at the frame of 
which the number has the same 3 LSB as the 
specified frame offset. If the current frame is 
specified, the MSS should start reporting in 
8 frames 


Duration (d) 


4 bits 


A CQI feedback is transmitted on the CQI 
channels indexed by the (CQI Channel 
Index) by the SS for 2 (d4) frames. If d is 
ObOOOO, the CQICH is de-allocated. If d is 
Obllll, the MSS should report until the BS 
command for the MSS to stop. 


} else { 






reserved 


3 bits 


Shall be set to zero 


\ } 






} 







Allocation Index 

Indicates its position from the start of the CQICH region. 
Period 

Informs the SS of the period of CQI reports. 
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Frame offset 

Informs the SS of when to start. The SS starts reporting at the frame of which the number has the 
same 3 LSB as the specified frame offset. If the current frame is specified, the SS should start 
reporting in 8 frames. 
Duration 

Indicates when the SS should stop reporting unless the CQICH allocation is refreshed beforehand. 
If duration d == ObOOOO, the BS is intended to de-allocate the CQICH. If d == Obllll, the CQICH 
is allocated indefinitely and the SS should report until the BS commands the SS to stop, which hap- 
pens it receives another MAPJE with d =0b0000. 

6.3.2.3.43.6 Compact DL-MAP IE 

6.3.2.3.43.6.1 Compact DL-MAP IE for normal subchannel 

The format of Compact DL-MAP IE for normal subchannel is presented in Table 96. 



Table 96— H-ARQ Compact_DL-MAP IE format for normal subchannel 



Syntax 


Size 


Notes 


Compact_DL-MAP_IE () { 






DL-MAP Type =0 


3 bits 




UL-MAP append 


lbit 




RCIDJE 


variable 




Ngp code 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 


N SCH code 


4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


H-ARQ_ControlJE 


variable 




CQICHControlJE 


variable 




if (UL-MAP append) { 






N EP code for UL 


4 bits 




Nsch c °d e f° r UL 


4 bits 




H-ARQ_Control_IE for UL 


variable 




} 






} ' 







DL-MAP Type 

This value specifies the type of the compact DL-MAP IE. A value of 0 indicates the Normal 
Subchannel. 
UL-MAP append 

A value of 1 indicates the uplink access information is appended to the end of the DL-MAP IE. 
RCIDJE 

Represent the assignment of the IE. 
NEP code, N SC h code 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the DL burst. 
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N EP code for UL, N SCH code for UL 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the UL burst. 

6.3.2.3.43.6.2Compact DL-MAP IE for Band AMC Subchannel 

The format of Compact DL-MAP IE for Band AMC Subchannel is presented in Table 97. 



Table 97— H-ARQ Compact_DL-MAP IE format for band AMC 



Syntax 


Size 


Notes 


Compact_DL-MAP JE () { 






DL-MAP Type =1 


3 bits 




reserved 


lbit 


Shall be set to zero 


RCIDJE 


variable 




N EP code 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 


N SCH code 


4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


Nband 


Nb-Band bits 


Number of bands, 0 = use BITMAP instead 


11 (IN Dana == uj { 






Band DllMAr 


IN D-r>l 1 MAr DltS 


jz-tn L.d£> is 1 11 Ai-tn Dana is seiectea 


) else ( 






/V_ /V i r- \TUnn A • it i \ 

tor (i=U;i< iNDand, i++) 






nana index 


iND-index Dits 


Band selection. 


} 






Allocation Mode 


2 bits 


Indicates the subchannel allocation mode. 

00 = same number of subchannels for the 

selected bands 

01 = different number of subchannels for the 

selected bands i 

10 = total number of subchannels for the \ 

selected bands determined by N SCH code j 
and N EP code 

11 = reserved j 


reserved 


2 bits 


Shall be set to zero 


if (Allocation Mode = 00) { 






No. Subchannels 


8 bits 




} else if (Allocation Mode == 01) { 






for (i*=0;/< band count; /++) 




If Nband is 0, band count is the number of "1" 
in Band BITMAP. Otherwise band count is 
Nband. 


No. Subchannels 


8 bits 




} 
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Table 97— H-ARQ Compact_DL-MAP IE format for band AMC (continued) 



Syntax 


Size 


Notes 


H-ARQ_Control_IE 


variable 




CQICH^ControlJE 


variable 




} 







DL-MAP Type 

This value specifies the type of the compact DL-MAP IE. A value of 1 indicates the Band AMC 
Subchannel. 
RCIDJE 

Represents the assignment of the IE. 
N EP code, N SCH code 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the DL burst. 
Nband 

Indicates the number of bands selected for the burst. If this value is set to 0, the Band BITMAP is 
used to indicate the number and the position of selected bands instead. The number of the 
maximum logical bands determines the length of this field. 
Band BITMAP 

This BITMAP is valid when Nband is 0. The n-th LSB of the Band BITMAP is set to 1 when the 
/z-th logical band is selected for the burst. If the number of the maximum logical bands is 12 then 
the length of the Band BITMAP is 12 bits. The band count is set to the number of 'T's in the Band 
BITMAP. The number of the maximum logical bands determines the length of this field. 
Band Index 

This value indexes the selected band offset and is valid when Nband is larger than 0. The number of 
the maximum logical bands determines the length of this field. 
Allocation Mode 

This value indicates the subchannel allocation mode in the selected bands. The value is set to 
binary 00 when the same numbers of subchannels are allocated in the selected bands by the "No. 
Subchannels" field. The value is set to 01 when different numbers of subchannels are allocated in 
each selected bands by the following fields "No. Subchannels." The value is set to 10 when the 
total number of subchannels allocated in the selected bands is defined by N SCH code and N EP code. 
The subchannels fill from the bands with lowest index. The allocation mode variant is shown in 
Figure 23. 
No. Subchannels 

This value indicates the number of subchannels allocated for this burst. 
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No; Subchannels 

: . . .. .. .. > • 




No: Subchannels 0 

4 . .. . ... .. » 




No. Subchannels 3 

.4 — ; ; — : — » 



AttaGatipn Mode =• 00 



Allocation Mode = 01 



Albeation Mode 10 

Nep: and Nsch dfitennmes &e total namher 
of subctowad^ (a+ b* d>, 



Available regions in ffie sql^fed band 
Occupied region by others: 
Albcatedregion 

Figure 23— Subchannel allocation modes of Compact DL-MAPJE for Band AMC 



6.3.2.3.43.6.3Compact DL-MAP IE for safety subchannel 

The format of Compact DL-MAP IE for safety subchannel is presented in Table 98. 



Table 98— H-ARQ Compact_DL-MAP IE format for safety 



Syntax 


Size 


Notes 


Compact_DL-MAP_IE () { 






DL-MAP Type =2 


3 bits 




UL-MAP append 


lbit 




RCID_IE 


variable 




N EP code 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 


N SCH code 


4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


BIN offset 


8 bits 




H-ARQ_ControlJE 


variable 




CQICH.ControlJE 


variable 




if (UL-MAP append) { 






N EP code for UL 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 
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Table 98 — H-ARQ Compact_DL-MAP IE format for safety (continued) 



Syntax 


Size 


Notes 


N SCH code for UL 


4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


BIN offset for UL 


8 bits 




H-ARQ_Control_IE for UL 


variable 




} 






} 







DL-MAP Type 

This value specifies the type of the compact DL-MAP IE. A value of 2 indicates the Safety 
Subchannel. 
RCIDJE 

Represent the assignment of the IE. 
N EP code, N SCH code 

The combination of N EP code and N SC n code indicates the number of allocated subchannels and 
scheme of coding and modulation for the DL burst. 
BIN Offset 

The offset of the BIN allocated for this DL burst. See appropriate specification. 
N EP code for UL, N SCH code for UL 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the UL burst. 
BIN Offset for UL 

The offset of the BIN allocated for this UL burst. See appropriate specification. 
6.3.2.3.43.6.4Compact DL-MAP IE for DIUC subchannel 

The format of Compact DL-MAP IE for DIUC subchannel is presented in Table 99. 



Table 99 — H-ARQ Compact_DL-MAP IE format for DIUC subchannel 



Syntax 


Size 


Notes 


Compact_DL-MAP_IE 0 { 






DL-MAP Type =3 


3 bits 




reserved 


1 bit 


Shall be set to zero 


DIUC 


4 bits 




RCIDJE 


variable 




No. Subchannels 


8 bits 


The number of subchannels allocated by the IE 


} 







DL-MAP Type 

This value specifies the type of the compact DL-MAP IE. A value of 3 indicates the DIUC type. 
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DIUC 

This value indicates the usage of this burst. 
RCIDJE 

Represent the assignment of the IE. 
No. Subchannels 

This value indicates the number of subchannels allocated by the IE. 
6.3.2.3.43.6.5Compact DL-MAP IE for H-ARQ ACK BITMAP 

The H-ARQ_ACK_Bitmap information for the H-ARQ enabled UL bursts is delivered through the 
Compact_DL-MAP_IE as shown in Table 100. The bit position in the bitmap is determined by the order of 
the H-ARQ enabled UL bursts in the UL-MAR The frame offset between the UL burst and the H-ARQ- 
ACK-BITMAP is specified by "H-ARQ_ACK_Delay_for UL Burst" field in the DCD message. 

For example, when an SS transmits a H-ARQ enabled burst at i-th frame and the burst is >th H-ARQ 
enabled burst in the MAP, the SS should receive H-ARQ ACK at j-th bit of the BITMAP, which is sent by 
the BS at /+(frame offset)-th frame. 



Table 100— H-ARQ Compact_DL-MAP IE format for H-ARQ BITMAP 



Syntax 


Size 


Notes 


Compact_DL-MAP_IE () { 






DL-MAP Type =5 


3 bits 




reserved 


lbit 


Shall be set to zero 


BITMAP Length 


4 bits 


Length in bytes 


BITMAP 


variable 




} 







DL-MAP Type 

Defines the type of Compact DL-MAP. If the type value is 5, the Compact DL-MAP is for H-ARQ- 
ACK-BITMAP. 
BITMAP Length 

Specifies the length of the following BITMAP field. 
BITMAP 

Includes H-ARQ ACK information for H-ARQ enabled UL bursts. The size of BITMAP should be 
equal or larger than the number of H-ARQ enabled UL-bursts. 
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6.3.2.3.43.6.6Compact DL-MAP IE for extension 

The format of Compact DL-MAP IE for extension is presented in Table 101. 



Table 101— H-ARQ Compact_DL-MAP IE format for extension 



Syntax 


Size 


Notes 


Compact_DL-MAP_IE () { 






DL-MAP Type =7 


3 bits 




DL-MAP subtype 


5 bits 


Extension subtype 


Length 


4 bits 


Length of the IE in bytes 


Payload 


variable 


Subtype dependent payload 


} 







DL-MAP Type 

This value specifies the type of the compact DL-MAP IE. A value of 7 indicates the extension type. 
DL-MAP Subtype 

This value specifies the subtype of the compact DL-MAP IE. 
Length 

This indicates the length of this IE in bytes. If an SS cannot recognize the DL-MAP Subtype, it 
skips the IE. 
Payload 

The payload depends on the value of DL-MAP Subtype. The length of payload is Length - 1 bytes. 
6.3.2.3.43.7 UL-MAPJE 

6.3.2.3.43.7.1 Compact UL-MAP IE for normal subchannel 

The format of Compact UL-MAP IE for normal subchannel is presented in Table 102. 



Table 102— H-ARQ Compact_UL-MAP IE format for normal subchannel 



Syntax 


Size 


Notes 


CompactJJL-MAPJE () { 






UL-MAP Type =0 


3 bits 




reserved 


lbit 


Shall be set to zero 


RCIDJE 


variable 




N EP code 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 




4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


H-ARQ_Control_IE 


variable 




} 
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UL-MAP Type 

This value specifies the type of the compact UL-MAP IE. A value of 0 indicates the Normal 
Subchannel. 
RCIDJE 

Represent the assignment of the IE. 
N EP code, N SCH code 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the UL burst. 

6.3.2.3.43.7.2Compact UL-MAP IE for Band AMC Subchannel 

The format of Compact UL-MAP IE for Band AMC Subchannel is presented in Table 103. 



Table 103— H-ARQ Compact_UL-MAP IE format for band AMC 



Syntax 


Size 


Notes 


Compact_UL-MAP_IE () { 






UL-MAP Type =band 


3 bits 




reserved 


lbit 


Shall be set to zero 


RCIDJE 


variable 




N EP code 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 


I NcrH code 


4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


Nband 


Nb-Band bits 


Indicates the number of selected bands. 

0 = BITMAP indicates the number and offset 

of selected bands 


if (Nband == 0) { 






Band BITMAP 


Nb-BITMAP bits 


n-th LSB is 1 if n-th band is selected 


} else { 






for (i=0;i< Nband; i++) 






Band Index 


Nb-Index bits 


Band selection. 


} 






! Allocation Mode 


2 bits 


Indicates the subchannel allocation mode. 

00 = same number of subchannels for the 

selected bands 

01 = different number of subchannels for the 

selected bands 

10 = total number of subchannels for the 

selected bands determined by N SCH code 

11 = reserved 


reserved 


2 bits 


Shall be set to zero 


if (Allocation Mode == 00) { 






No. Subchannels 


8 bits 




} else if (Allocation Mode == 1){ 
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Table 103— H-ARQ Compact_UL-MAP IE format for band AMC (continued) 



Syntax 


Size 


Notes 


for (i=0;i< band count; /++) 




If Nband is 0, band count is the number of "1" 
in Band BITMAP. Otherwise band count is 
Nband. 


No. Subchannels 


8 bits 




} 






H-ARQ_Control_IE 


variable 




I 







UL-MAP Type 

This value specifies the type of the compact UL-MAP IE. A value of 1 indicates the Band AMC 
Subchannel 
RCID_IE 

Represent the assignment of the IE. 
N EP code, N SCH code 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the UL burst. 
Nband 

Indicates the number of bands selected for the burst. If this value is set to 0, the Band BITMAP is 
used to indicate the number and the position of selected bands instead. The number of the 
maximum logical bands determines the length of this field. 
Band BITMAP 

This BITMAP is valid when Nband is 0. The n-th LSB of the Band BITMAP is set to 1 when the n- 
th logical band is selected for the burst. If the number of the maximum logical bands is 12, then the 
length of the Band BITMAP is 12 bits. The band count is set to the number of "l"s in the Band 
BITMAP. The number of the maximum logical bands determines the length of this field. 
Band Index 

This value indexes the selected band offset and is valid when Nband is larger than 0. The number of 
the maximum logical bands determines the length of this field. 
Allocation Mode 

This value indicates the subchannel allocation mode in the selected bands. The value is set to 
binary 00 when the same numbers of subchannels are allocated in the selected bands by the 
following field "No. Subchannels." The value is set to 01 when different numbers of subchannels 
are allocated in each selected bands by the following fields "No. Subchannels." The value is set to 
10 when the total number of subchannels allocated in the selected bands is defined by N SCH code 
and N EP code. The subchannels fill from the bands with lowest index. The allocation mode variant 
is shown in Figure 23. 
No. Subchannels 

This value indicates the number of subchannels allocated for this burst. 
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6.3.2.3.43.7.3Compact UL-MAP IE for safety subchannel 

The format of Compact UL-MAP IE for safety subchannel is presented in Table 98. 



Table 104— H-ARQ Compact_UL-MAP IE format for safety 



Syntax 


Size 


Notes 


Compact_UL-MAPJE () { 






UL-MAP Type =2 


3 bits 




reserved 


lbit 


Shall be set to zero 


RCIDJE 


variable 




N EP code 


4 bits 


Code of encoder packet bits (see 8.4.9.2.3.5) 


N SCH codt 


4 bits 


Code of allocated subchannels (see 8.4.9.2.3.5) 


BIN offcet 


8 bits 




H-ARQ ControLIE 


variable 




} 







UL-MAP Type 

This value specifies the type of the compact UL-MAP IE. A value of 2 indicates the Safety 
Subchannel. 
RCIDJE 

Represents the assignment of the IE. 
N EP code, N SCH code 

The combination of N EP code and N SCH code indicates the number of allocated subchannels and 
scheme of coding and modulation for the UL burst. 
BIN Offset 

The offset of the BIN allocated for this UL burst. 
6.3.2.3.43.7.4Compact UL-MAP IE for UIUC subchannel 

The format of Compact UL-MAP IE for UIUC subchannel is presented in Table 105. 

Table 105— H-ARQ Compact_UL-MAP IE format for UIUC subchannel 



Syntax 


Size 


Notes 


CompactJJL-MAPJE () { 






UL-MAP Type =4 


3 bits 




reserved 


lbit 


Shall be set to zero 


UIUC 


4 bits 
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Table 105— H-ARQ Compact_UL-MAP IE format for UIUC subchannel (continued) 



I Syntax 


Size 


Notes 


RCIDJE 


variable 




No. Subchannels 


8 bits 


The number of subchannels allocated by the IE 


) 







UL-MAP Type 

This value specifies the type of the compact UL-MAP IE. A value of 3 indicates the UIUC type. 
UIUC 

This value indicates the usage of this burst. 
RCIDJE 

Represents the assignment of the IE. 
No, Subchannels 

This value indicates the number of subchannels allocated by the IE. 
6.3.2.3.43.7.5Compact UL-MAP IE for H-ARQ Region allocation 

The H-ARQ ACK region information is delivered through the Compact_UL-MAPJE as shown in 
Table 106. SS sends ACK information for H-ARQ enabled DL bursts in the H-ARQ region specified by the 
IE. 

The subchannels in the H-ARQ region are divided into two half-subchannels. The first half-subchannel is 
composed of first, third, and fifth tiles, and the second half-subchannel is composed of second, fourth, and 
sixth tiles. In the H-ARQ Region, the 2n-th half-subchannel is the first half-subchannel and the (2/i+ 7)-th 
half-subchannel is the second half-subchannel of the n-th subchannel. 

The H-ARQ enabled SS that receives H-ARQ DL burst at i-th frame should transmit ACK signal through 
the half-subchannel in the H-ARQ region at (/+/>th frame. The frame offset is defined by the "H-ARQ 
ACK Delay for DL Burst" field in the UCD message. The half-subchannel offset in the H-ARQ Region is 
determined by the order of H-ARQ enabled DL burst in the H-ARQ MAP. For example, when an SS 
receives a H-ARQ enabled burst at i-th frame and the burst is n-th H-ARQ enabled burst in the H-ARQ 
MAP, the SS should transmit H-ARQ ACK at n-th half-subchannel in H-ARQ Region that is allocated by 
the BS at the (*+/)-th frame. 



Table 106— H-ARQ Compact_UL-MAP IE format for H-ARQ Region allocation 



Syntax 


Size 


Notes 


Compact_UL-MAP_IE () { 






UL-MAP Type »4 


3 bits 




H-ARQ Region Change Indication 


1 bit 


0: no region change 
1: region changed 


if (H-ARQ Region Change Indication ==!){. 






OFDMA Symbol oflfset 


8 bits 




Subchannel offset 


8 bits 




No. OFDMA Symbols 


8 bits 
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Table 106— H-ARQ Compact_UL-MAP IE format for H-ARQ Region allocation (continued) 



Syntax 


Size 


Notes 


No. Subchannels 


8 bits 




! } 






} 







UL-MAPType 

Defines the type of Compact UL-MAP. If the type value is 4, the Compact UL-MAP is for H-ARQ 
Region allocation. 

H-ARQ Region Change Indication 

Indicates whether the region for H-ARQ ACK is changed or not. 
OFDMA Symbol offset 
Subchannel offset 
No. OFDMA Symbols 
No. Subchannels 

Specify the start symbol offset, the start subchannel offset, the number of allocated symbols, and 
the number of subchannels for the H-ARQ acknowledgement region respectively. 

6.3.2.3.43.7.6Compact UL-MAP IE for CQICH Region allocation 

The CQI region information is delivered through the Compact_UL-MAP_IE as shown in Table 107. SS 
sends CQI report in CQI region. 



Table 107— H-ARQ Compact_UL-MAP IE format for CQI Region allocation 



Syntax 


Size 


Notes 


Compact_UL-MAP_IE () { 






UL-MAPType =5 


3 bits 




CQI Region Change Indication 


1 bit 


0: no region change 
1: region changed 


if (CQI Region Change Indication == 1) { 






OFDMA Symbol offset 


8 bits 




Subchannel offset 


8 bits 




No. OFDMA Symbols 


8 bits 




No. Subchannels 


8 bits 




} 






} 







UL-MAPType 

Defines the type of Compact UL-MAP. If the type value is 5, the Compact UL-MAP is for CQI 
Region allocation. 
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CQI Region Change Indication 
Indicates whether the region for CQI is changed or not. 
OFDMA Symbol offset 
Subchannel offset . 
No. OFDMA Symbols 
No. Subchannels 

Specify the start symbol offset, the start subchannel offset, the number of allocated symbols, and 
the number of subchannels for the CQI report region respectively. 

6.3.2.3.43.7.7Compact UL-MAP IE for extension 

The format of Compact UL-MAP IE for extension is presented in Table 108. 



Table 108 — H-ARQ Compact_UL-MAP IE format for extension 



Syntax 


Size 


Notes 


Compact_UL-MAP_IE 0 { 






UL-MAP Type =7 


3 bits 




UL-MAP subtype 


5 bits 


Extension subtype 


Length 


4 bits 


Length of the IE in bytes 


Payload 


variable 


Subtype dependent payload 


} 







UL-MAP Type 

Specifies the type of the compact UL-MAP IE. A value of 7 indicates the extension type. 
UL-MAP Subtype 

Specifies the subtype of the compact UL-MAP IE. 
Length 

Indicates the length of this IE in bytes. If an SS cannot recognize the UL-MAP Subtype, it skips the 
IE. 

Payload 

The payload depends on the value of UL-MAP Subtype. The length of payload is Length - 1 bytes. 



6.3.3 Construction and transmission of MAC PDUs 

The construction of a MAC PDU is illustrated in Figure 24. 
6.3.3.1 Conventions 

Data shall be transmitted in accordance with the following rules: 

a) Fields of MAC messages are transmitted in the same order as they appear in the corresponding 
tables in this standard. 

b) Fields of MAC messages and fields of TLVs, which are specified in this standard as binary numbers 
(including CRC and HCS), are transmitted as a sequence of their binary digits, starting from MSB. 
Bit masks (for example, in ARQ) are considered numerical fields. For signed numbers MSB is 
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allocated for the sign. Length field in the "definite form" of ITU-T X.690 is also considered a 
numerical field. 

c) Fields specified as SDUs or SDU fragments (for example, MAC PDU payloads) are transmitted in 
the same order of bytes as received from upper layers. 

d) Fields specified as strings are transmitted in the order of symbols in the string. 

In cases c) and d), bits within a byte are transmitted in the order "MSB first." 




\ fits? / 

\ttJOTE)/ 

Yes Y 






Add Packing 


Fragment SDU; 


subheader; 


add Packing 


add SDU or 


subheader; 


SDU fragment 


add fragment 





NOTE: "Fragment/SDU fits?" means: 
"Does the fragment left over from the 
last time, or the next SDU if no 
fragment was left over, fit in the 
available bandwidth?" 



Yes 



< 


r 




Add Fragmenta- 
tion subheader 







Add SDU to 
payload 



Add Fragmenta- 
tion subheader 
& SDU fragment 
to payload 




No 



Fragment the 
SDU fragment & 
add to payload 




No /Encrypt^ 
.payload. 



Encrypt 



Apply Generic 
MAC Header 




Include CRC 
length in header 
length field 




F 


Calculate 
and append 
CRC 


i 


r 



Concatenate 
PDU to up/down- U- 
link burst 



Add fragmented 
SDU fragment 
to payload 



Figure 24— Construction of a MAC PDU 
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6.3.3.2 Concatenation 

Multiple MAC PDUs may be concatenated into a single transmission in either the uplink or downlink 
directions. Figure 25 illustrates this concept for an uplink burst transmission. Since each MAC PDU is 
identified by a unique CID, the receiving MAC entity is able to present the MAC SDU (after reassembling 
the MAC SDU from one or more received MAC PDUs) to the correct instance of the MAC SAP. MAC 
Management messages, user data, and bandwidth request MAC PDUs may be concatenated into the same 
transmission. 



Uplink Burst #n 



x 



Uplink Burst #n+1 



> 



User 


Bandwidth 




Management 


User 


User 


PDU 


Request PDU 




PDU 


PDU 


PDU 


CID = 0x2301 


CID = 0x0399 


CID = 0x0EF1 " 


CID = 0x5F3E 


CID = 0x2555 



Figure 25 — MAC PDU concatenation showing example CIDs 



6.3.3.3 Fragmentation 

Fragmentation is the process by which a MAC SDU is divided into one or more MAC PDUs. This process is 
undertaken to allow efficient use of available bandwidth relative to the QoS requirements of a connection's 
service flow. Capabilities of fragmentation and reassembly are mandatory. 

The authority to fragment traffic on a connection is defined when the connection is created by the MAC 
SAP. Fragmentation may be initiated by a BS for downlink connections and by an SS for uplink connections. 



Fragments are tagged with their position in their parent SDU in accordance with Table 109. 



Table 109— Fragmentation rules 



Fragment 


Fragmentation control (FC) 


First Fragment 


10 


Continuing Fragment 


11 


Last Fragment 


01 


Unfragmented 


00 



6.3.3.3.1 Non-ARQ Connections 



For non-ARQ connections, fragments are transmitted once and in sequence. The sequence number assigned 
to each fragment allows the receiver to recreate the original payload and to detect the loss of any 
intermediate packets. A connection may be in only one fragmentation state at any given time. 

Upon loss, the receiver shall discard all MAC PDUs on the connection until a new first fragment is detected 
or a non-fragmented MAC PDU is detected. 
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6.3.3.3.2 ARQ-Enabled Connections 

For ARQ-enabled connections, fragments are formed for each transmission by concatenating sets of ARQ 
blocks with adjacent sequence numbers (see 63.4.2). The BSN value carried in the fragmentation subheader 
is the BSN for the first ARQ block appearing in the segment. 

6.3.3.4 Packing 

If packing is turned on for a connection, the MAC may pack multiple MAC SDUs into a single MAC PDU. 
Packing makes use of the connection attribute indicating whether the connection carries fixed-length or 
variable-length packets. The transmitting side has full discretion whether or not to pack a group of MAC 
SDUs in a single MAC PDU. The capability of unpacking is mandatory. 

The construction of PDUs varies for ARQ and non-ARQ connections with respect to packing and 
fragmentation syntax. The packing and fragmentation mechanisms for both the ARQ and non-ARQ 
connections are specified in 6.3.3.4.1 through 6.3.3.4.3. 

6.3.3.4.1 Packing for non-ARQ connections 

6.3.3.4.1.1 Packing fixed-length MAC SDUs 

For connections that do not use ARQ and are indicated by the fixed-length versus variable-length SDU 
indicator (11.13.15), to carry fixed-length MAC SDUs, the packing procedure described in this subclause 
may be used. For all other non-ARQ connections, the variable length packing algorithm described in 

6.3.3.4.1.2 shall be used. 

For packing with fixed-length blocks, the Request/Transmission Policy (11.13.12) shall be set to allow 
packing and prohibit fragmentation, and the SDU size (11.13.16) shall be included in DSA-REQ message 
when establishing the connection. The length field of the MAC header implicitly indicates the number of 
MAC SDUs packed into a single MAC PDU. If the MAC SDU size is n bytes, the receiving side can unpack 
simply by knowing that the length field in the MAC header will be nxk+j, where k is the number of MAC 
SDUs packed into the MAC PDU and j is the size of the MAC header and any prepended MAC subheaders. 
A MAC PDU containing a packed sequence of fixed-length MAC SDUs would be constructed as in Figure 
26. Note that there is no added overhead due to packing in the fixed-length MAC SDU case, and a single 
MAC SDU is simply a packed sequence of length 1. 

r* k MAC SDUs — K 



Fixed-length 
MAC SDU 
length = n 



Figure 26— Packing fixed-length MAC SDUs into a single MAC PDU 
6.3.3.4.1.2 Packing variable-length MAC SDUs 

When packing variable-length SDU connections, such as 802.3/Ethernet, the nxk+j relationship between the 
MAC header's length field and the higher-layer MAC SDUs no longer holds. This necessitates indication of 
where one MAC SDU ends and another begins. In the variable-length MAC SDU case, the MAC attaches a 
Packing subheader to each MAC SDU. This subheader is described in 6.3.2.2.3. 
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A MAC PDU containing a packed sequence of variable-length MAC SDUs is constructed as shown in 
Figure 27. If more than one MAC SDU is packed into the MAC PDU, the type field in the MAC header 
indicates the presence of Packing subheaders (PSHs). Note that unfragmented MAC SDUs and MAC SDU 
fragments may both be present in the same MAC PDU (see Figure 28). 
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Figure 27— Packing variable-length MAC SDUs into a single MAC PDU 



Simultaneous fragmentation and packing allows efficient use of the airlink, but requires guidelines to be 
followed so it is clear which MAC SDU is currently in a state of fragmentation. To accomplish this, when a 
Packing subheader is present, the fragmentation information for individual MAC SDUs or MAC SDU 
fragments is contained in the corresponding Packing subheader. If no PSH is present, the fragmentation 
information for individual MAC SDU fragments is contained in the corresponding Fragmentation subheader 
(FSH). This is shown in Figure 28. 
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Figure 28— Packing with fragmentation 



Note that while it is legal to have continuation fragments packed with other fragments, the circumstances for 
creating continuation fragments would preclude this from happening. 
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6.3.3.4.2 Packing for ARQ-enabled connections 

The use of Packing subheaders for ARQ-enabled connections is similar to that for non-ARQ connections as 
described in 6.3.3 A 1.2, except that ARQ-enabled connections shall set the Extended Type bit (see Table 6) 
in the generic MAC header to 1. If packing is turned on for a connection, the MAC may pack multiple MAC 
SDUs into a single MAC PDU. The transmitting side has full discretion whether or not to pack a group of 
MAC SDUs and/or fragments in a single MAC PDtL 

The packing of variable-length MAC SDUs for the ARQ-enabled connections is similar to that of non-ARQ 
connections, when fragmentation is enabled. The BSN of the Packing subheader shall be used by the ARQ 
protocol to identify and retransmit lost fragments. 

For ARQ-enabled connections, when the type field indicates Packing subheaders are in use, fragmentation 
information for each individual MAC SDU or MAC SDU fragment is contained in the associated Packing 
subheader. When the type field indicates that packing is not in use, fragmentation information for the MAC 
PDU's single payload (MAC SDU or MAC SDU fragment) is contained in the fragmentation header appear- 
ing in the message. Figure 29 illustrates the use of Fragmentation subheader without packing. 
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Figure 29— Example MAC PDU with extended Fragmentation subheaders 



Figure 30 illustrates the structure of a MAC PDU with ARQ Packing subheaders. Each of the packed MAC 
SDU or MAC SDU fragments or ARQ feedback payload requires its own Packing subheader and some of 
them may be transmissions while others are retransmissions. 
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Figure 30— Example MAC PDU with ARQ Packing subheader 



A MAC SDU may be partitioned into multiple fragments that are then packed into the same MAC PDU for 
the first transmission. MAC PDUs may have fragments from the same or different SDUs, including a mix of 
first transmissions and retransmissions. The 11 -bit BSN and 2-bit FC fields uniquely identify each fragment 
or non-fragmented SDU. 

6.3.3.4.3 Packing ARQ Feedback IEs 

An ARQ Feedback Payload (see Table 110) consists of one or more ARQ Feedback IEs (see 6.3.4.2). The 
ARQ Feedback Payload may be sent on an ARQ or non-ARQ connection; however, policies based on imple- 
mentation and/or QoS constraints may restrict the use of certain connections for transporting ARQ Feedback 
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Payload. The ARQ Feedback Payload is treated like any other payload (SDU or fragments) from the packing 
perspective, except that only one ARQ Feedback Payload shall be present within a single MAC PDU. 



Table 110 — ARQ Feedback Payload format 



Syntax 


Size 


Notes 


ARQ_Feedback_Payload_Format() { 






do 






ARCLFeedbackJE(last) 


variable 


Insert as many as desired, until last==TRUE. 
See 6.3.4.2. 


until (last) 






} 







The presence of an ARQ Feedback Payload in a MAC PDU is indicated by the value of the ARQ Feedback 
Payload bit in the Type field (see Table 6) in the generic MAC header. When present, the first packed 
payload shall be the ARQ Feedback Payload. The Packing subheader preceding the ARQ Feedback Payload 
indicates the total length of the payload including the Packing subheader and all ARQ Feedback IEs within 
the payload. The FSN/BSN field of the Packing subheader shall be ignored for the ARQ Feedback Payload 
and the FC bits shall be set to 00. 

6.3.3.5 CRC calculation 

A service flow may require that a CRC be added to each MAC PDU carrying data for that service flow 
(11.13.12). In this case, for each MAC PDU with HT=0, a CRC (as defined in IEEE Std 802.3), shall be 
appended to the payload of the MAC PDU; i.e., request MAC PDUs are unprotected. The CRC shall cover 
the generic MAC header and the Payload of the MAC PDU. The CRC shall be calculated after encryption; 
i.e., the CRC protects the Generic Header and the ciphered Payload. 

6.3.3.6 Encryption of MAC PDUs 

When transmitting a MAC PDU on a connection that is mapped to an SA, the sender shall perform 
encryption and data authentication of the MAC PDU payload as specified by that SA. When receiving a 
MAC PDU on a connection mapped to an S A, the receiver shall perform decryption and data authentication 
of the MAC PDU payload, as specified by that SA. 

The generic MAC header shall not be encrypted. The Header contains all the Encryption information 
[EC Field, encryption key sequence (EKS) Field, and CID] needed to decrypt a Payload at the receiving 
station. This is illustrated in Figure 31. 



Generic MAC header 



— yy 

Payload (optional) 

— yy 



CRC 
(Optional) 



V 

Encrypted portion of the MAC PDU 
Figure 31— MAC PDU encryption 
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Two bits of a MAC Header contain a key sequence number. Note that the keying material associated with an 
SA has a limited lifetime, and the BS periodically refreshes an SA's keying material. The BS manages a 2-bit 
key sequence number independently for each SA and distributes this key sequence number along with the 
SAs keying material to the client SS. The BS increments the key sequence number with each new 
generation of keying material. The MAC Header includes this sequence number to identify the specific 
generation of that SA keying material being used to encrypt the attached payload. Being a 2-bit quantity, the 
sequence number wraps around to 0 when it reaches 3. 

Comparing a received MAC PDU's key sequence number with what it believes to be the "current" key 
sequence number, the SS or the BS can easily recognize a loss of key synchronization with its peer. An SS 
shall maintain the two most recent generations of keying material for each SA. Keeping on hand the two 
most recent key generations is necessary for maintaining uninterrupted service during an SA's key transition. 

Encryption of the payload is indicated by the EC bit field. A value of 1 indicates the payload is encrypted 
and the EKS field contains meaningful data. A value of 0 indicates the payload is not encrypted. Any 
unencrypted MAC PDU received on a connection mapped to an S A requiring encryption shall be discarded. 

6.3.3.7 Padding 

Allocated space within a data burst that is unused shall be initialized to a known state. This may be 
accomplished by setting each unused byte to the stuff byte value (OxFF). If the size of the unused region is at 
least the size of a MAC header, the region may also be initialized by formatting the unused space as an MAC 
PDU. When doing so, the MAC header CID field shall be set to the value of the Padding CID (see Table 
345), the CI, EC, HT, and Type fields shall be set to zero, the length field shall be set to the number of 
unused bytes (including the size of the MAC header created for the padding MAC PDU) in the data burst, 
and the HCS shall be computed in the normal way. 

6.3.4 ARQ mechanism 

ARQ shall not be used with the PHY specification defined in 8.1. 

The ARQ mechanism is a part of the MAC, which is optional for implementation. When implemented, ARQ 
may be enabled on a per-connection basis. The per-connection ARQ shall be specified and negotiated during 
connection creation. A connection cannot have a mixture of ARQ and non-ARQ traffic. Similar to other 
properties of the MAC protocol the scope of a specific instance of ARQ is limited to one unidirectional 
connection. 

For ARQ-enabled connections, enabling of fragmentation is optional. When fragmentation is enabled, the 
transmitter may partition each SDU into fragments for separate transmission based on the value of the 
ARQ_BLOCK_SIZE parameter. When fragmentation is not enabled, the connection shall be managed as if 
fragmentation was enabled. In this case, regardless of the negotiated block size, each fragment formed for 
transmission shall contain all the blocks of data associated with the parent SDU. 

The ARQ feedback information can be sent as a standalone MAC management message on the appropriate 
basic management connection, or piggybacked on an existing connection. ARQ feedback cannot be 
fragmented. The implementation of ARQ is optional. 

6.3.4.1 ARQ Block Usage 

A MAC SDU is logically partitioned into blocks whose length is specified by the connection TLV parameter 
ARQ_BLOCK_SIZE. When the length of the SDU is not an integer multiple of the connection's block size, 
the final block of the SDU is formed using the SDU bytes remaining after the final full block has been 
determined. 
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Once an SDU is partitioned into a set of blocks, that partitioning remains in effect until all blocks of the 
SDU are successfully delivered to the receiver, or the SDU is discarded by the transmitter state machine. 

Sets of blocks selected for transmission or retransmission are encapsulated into a PDU. A PDU may contain 
blocks that are transmitted for the first time as well as those being retransmitted. Fragmentation shall occur 
only on ARQ block boundaries. If a PDU is not packed, all the blocks in that PDU must have contiguous 
block numbers. When a PDU is packed, the sequence of blocks immediately between MAC subheaders and 
the sequence of blocks after the last packing subheader must have contiguous block numbers. 

If ARQ is enabled at the connection, Fragmentation and Packing subheaders contain a BSN, which is the 
sequence number of the first ARQ block in the sequence of blocks following the subheader. It is a matter of 
transmitter policy whether or not a set of blocks once transmitted as a single PDU should be retransmitted 
also as a single PDU. Figure 32 illustrates the use of blocks for ARQ transmissions and retransmissions; two 
options for retransmission are presented — with and without rearrangements of blocks. 
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Figure 32— Block usage examples for ARQ with and without rearrangement 
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6.3.4.2 ARQ Feedback IE format 

Table 111 defines the ARQ Feedback IE used by the receiver to signal positive or negative 
acknowledgments. A set of IEs of this format may be transported either as a packed payload 
("piggybacked") within a packed MAC PDU or as a payload of a standalone MAC PDU. 



Table 111— ARQ Feedback IE 



Syntax I 


Size 


Notes 


ARQ_feedback JE (LAST) { 


variable 




CID 


16 bits 


The ID of the connection being referenced 


LAST 


1 bit 


0 = More ARQ feedback IE in the list 

1 = Last ARQ feedback IE in the list 


ACK Type 


2 bits 


0x0 = Selective ACK entry 

0x1 = Cumulative ACK entry 

0x2 = Cumulative with Selective ACK entry 

0x3 = Cumulative ACK with Block Sequence Ack 

entry 


BSN 


1 1 bits 




Number of ACK Maps 


2 bits 


If ACK Type ==01, the field is reserved and set to 00. 
Otherwise the field indicates the number of ACK 
maps: 

OyO - 1 Oy1 - 9 Oy9 - 1 Oy^— & 

UAU — 1 , UA1 — jLj UAi — \J\J — *+ 


if SACK Tvnpl- OH f 

II ^/\v^iv lypei— ui ) \ 






LOT \l— u, k. i\umDcr OI 
ACK Maps+ 1; { 






if (ACK Type != 3) { 






Selective ACK Map 


16 bits 




} 






else { 




Start of Block Sequence ACK Map definition (16 bits) 


Sequence Format 


1 bit 


Number of block sequences associated with descriptor 
0: 2 block sequences 1 : 3 block sequences 


if (Sequence Format = 0) { 






Sequence ACK Map 


2 bits 




Sequence 1 Length 


6 bits 




Sequence 2 Length 


6 bits 




Reserved 


1 bit 




} 






else { 






Sequence ACK Map 


3 bits 




Sequence 1 Length 


4 bits 




Sequence 2 Length 


4 bits 
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Table 111— ARQ Feedback IE (continued) 



Syntax 


Size 


Notes 


Sequence 3 Length 


4 bits 




} 






} 




End of Block Sequence ACK Map definition 


} 






} 






} 







BSN 

If (ACK Type == 0x0): BSN value corresponds to the most significant bit of the first 16-bit ARQ 
ACK map. 

If (ACK Type == 0x1): BSN value indicates that its corresponding block and all blocks with lesser 
(see 6.3.4.6.1) values within the transmission window have been successfully received. 

If (ACK Type == 0x2): Combines the functionality of types 0x0 and 0x1. 

If (ACK Type == 0x3): Combines the functionality of type 0x1 with the ability to acknowledge 
reception of ARQ blocks in terms of block sequences. A block sequence is defined as a set of ARQ 
blocks with consecutive BSN values. With this option, members of block sequences are identified 
and associated with the same reception status indication. 

Selective ACK Map 

Each bit set to one indicates the corresponding ARQ block has been received without errors. The 
bit corresponding to the BSN value in the IE, is the most significant bit of the first map entry. The 
bits for succeeding block numbers are assigned left-to-right (MSB to LSB) within the map entry. If 
the ACK Type is 0x2, then the most significant bit of the first map entry shall be set to one and the 
IE shall be interpreted as a cumulative ACK for the BSN value in the IE. The rest of the bitmap 
shall be interpreted similar to ACK Type 0x0. 

Sequence ACK Map 

Each bit set to one indicates the corresponding block sequence has been received without error. The 
MSB of the field corresponds to the first sequence length field in the descriptor. The bits for 
succeeding length fields are assigned left-to-right within the map entry. 

Since the block sequence described by the first descriptor of the first map entry of the IE 
corresponds to the sequence of blocks immediately after the Cumulative ACK, the ACK map bit 
for this sequence shall be zero indicating this sequence has not yet been received. 

Sequence Length 

This value indicates the number of blocks that are members of the associated sequence. 

The BSN of the first block of the block sequence described by the first descriptor of the first IE map 
entry is the value of the Cumulative ACK plus one. The BSN of the first block of each block 
sequence is determined by adding the BSN of the first block of the previous block sequence to the 
length of that sequence. Within a map entry, Sequence Map/Length ordering follows the rule 
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specified in the definition of Sequence ACK Map. Across map entries, ordering moves from the 
first map entry (i = 0) to the last map entry (i = Number of ACK Maps). 

6.3.4.3 ARQ parameters 

6.3.4.3.1 ARQ_BSN_MODULUS 

ARQ_BSN_MOD ULUS is equal to the number of unique BSN values, i.e., 2 11 . 

6.3.4.3.2 ARQ_WINDOW_SIZE 

ARQ_WINDOW_SIZE is the maximum number of unacknowledged ARQ blocks at any given time. An 
ARQ block is unacknowledged if it has been transmitted but no acknowledgment has been received. 

ARQ_WINDOW_SIZE shall be less than or equal to half of the ARQJBSN_M OD ULUS. 

6.3.4.3.3 ARCLBLOCKJJFETIME 

ARQ__BLOCK_LIFETIME is the maximum time interval an ARQ block shall be managed by the transmitter 
ARQ state machine, once initial transmission of the block has occurred. If transmission (or subsequent 
retransmission) of the block is not acknowledged by the receiver before the time limit is reached, the block 
is discarded. 

6.3.4.3.4 ARQ_RETRY_TIMEOUT 

ARQ_RETRY_TIMEOUT is the minimum time interval a transmitter shall wait before retransmission of an 
unacknowledged block for retransmission. The interval begins when the ARQ block was last transmitted. 

6.3.4.3.5 ARQ_SYNC_LOSS_TIMEOUT 

ARQ_SYNC_LOSS_TIMEOUT is the maximum time interval ARQ_TX_WINDOWJ$TART or 
ARQ_RX_WINDOW_START shall be allowed to remain at the same value before declaring a loss of 
synchronization of the sender and receiver state machines when data transfer is known to be active. The 
ARQ receiver and transmitter state machines manage independent timers. Each has its own criteria for 
determining when data transfer is "active" (see 6.3.4.6.2 and 6.3.4.6.3). 

6.3.4.3.6 ARQ_RX_PURGE_TIMEOUT 

AR Q_RX_P URGE_TIMEO UT is the time interval the receiver shall wait after successful reception of a 
block that does not result in advancement of ARQJtX_WINDOW_START, before advancing 
ARQJLX_WINDOW_START{sze 6.3.4.6.3). 

6.3.4.3.7 ARCLBLOCK_SIZE 

ARQJBLOCK_SIZE is the length used for partitioning an SDU into a sequence of ARQ blocks prior to 
transmission (see 6.3.4. 1) V 

6.3.4.4 ARQ procedures 

6.3.4.4.1 ARQ state machine variables 

All ARQ state machine variables are set to 0 at connection creation or by an ARQ reset operation. 
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6.3.4.4.1.1 Transmitter variables 

ARQSXJW1ND0W_START\ All BSN up to (ARQ_TX_W!NDOW_START - 1) have been acknowledged. 

ARQ_TX_NEXT_BSN : BSN of the next block to send. This value shall reside in the interval 
ARQJTX_WINDOW_START to (ARQ_TX_WINDOW__START + ARQ_MNDOW_SIZE), inclusive. 

6.3.4.4.1.2 Receiver variables 

ARQ_RX_WINDOW_START. All BSN up to (ARQ_RX_WINDOW_START - 1) have been correctly 
received. 

ARQ_RX_H1GHESTJSN\ BSN of the highest block received, plus one. This value shall reside in the 
interval ARQ_RX_WINDOW_START to (ARQ_RX_WINDOW_START + ARQ_WINDOW_SIZE), 
inclusive. 

6.3.4.5 ARQ-enabled connection setup and negotiation 

Connections are set up and defined dynamically through the DSA/DSC class of messages. CRC-32 shall be 
used for error detection of PDUs for all ARQ-enabled connections. All the ARQ parameters (see 6.3.4.3) 
shall be set when an ARQ-enabled connection is set up. The transmitter and receiver variables (defined in 
6.3.4.4.1) shall be reset on connection setup. 

6.3.4.6 ARQ operation 

6.3.4.6.1 Sequence number comparison 

Transmitter and receiver state machine operations include comparing BSNs and taking actions based on 
which is larger or smaller. In this context, it is not possible to compare the numeric sequence number values 
directly to make this determination. Instead, the comparison shall be made by normalizing the values 
relative to the appropriate state machine base value and the maximum value of sequence numbers, 
ARQ_BSNJ40DULUS, and then comparing the normalized values. Normalization is accomplished by 
using Equation (8). 

bsn' = (bsn - BSN_base) mo d ARQ_BSNJMODULUS (8) 

The base values for the receiver and transmitter state machines are ARQ_TX_WINDOW_START and 
ARQ_RX_WINDOW_START, respectively. 

6.3.4.6.2 Transmitter state machine 

An ARQ block may be in one of the following four states — not-sent, outstanding, discarded, and waiting- 
for-retransmission. Any ARQ block begins as not-sent. After it is sent it becomes outstanding for a period of 
time termed A CK_RETRY JIMEOUT. While a block is in outstanding state, it is either acknowledged and 
discarded, or transitions to waiting-for- retransmission after ACK_RETRY JIMEOUT or NACK. An ARQ 
block can become waiting-for-retransmission before the ACK_RETRY_TIMEOUT period expires if it is 
negatively acknowledged. An ARQ block may also change from waiting-for-retransmission to discarded 
when an ACK message for it is received or after a timeout ARQ_BLOCK_LIFETIME. 

For a given connection the transmitter shall first handle (transmit or discard) blocks in "waiting-for- 
retransmission" state and only then blocks in "non-senf state. Blocks in "outstanding" or "discarded' state 
shall not be transmitted. When blocks are retransmitted, the block with the lowest BSN shall be 
retransmitted first. 
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The ARQ transmit block state sequence is shown in Figure 33. 



^ Not sent 




ACK 



Figure 33— ARQ transmit block states 



MAC PDU formation continues with a connection's "not-sent" MAC SDUs. The transmitter builds each 
MAC PDU using the rules for fragmentation and packing as long as the number of blocks to be sent plus the 
number of block already transmitted and awaiting retransmission does not exceed the limit imposed by 
ARQ_WINDOW_SlZE. As each "not-sent" block is formed and included in a MAC PDU, it is assigned the 
current value of ARQ_TX__NEXT_BSN, which is then incremented. 

When an acknowledgment is received, the transmitter shall check the validity of the BSN. A valid BSN is 
one in the interval ARQ_TX_WINDOW_START to ARQ_TX_NEXT_BSN - 1 (inclusive). If BSN is not valid, 
the transmitter shall ignore the acknowledgment. 

When a cumulative acknowledgment with a valid BSN is received, the transmitter shall consider all blocks 
in the interval ARQ_TXJVINDOW_START to BSN (inclusive) as acknowledged and set 
ARQ_TX_WINDOW_START to BSN + 1. 

When a selective acknowledgment is received, the transmitter shall consider as acknowledged all blocks so 
indicated by the entries in the bitmap for valid BSN values. As the bitmap entries are processed in increasing 
BSN order, ARQ_TXJVINDOW_START shall be incremented each time the BSN of an acknowledged block 
is equal to the value of ARQ_TX_WINDOW_START. 

When ARQ_TXJWINDOW_START has been advanced by either of the above methods and acknowledgment 
of reception has already been received for the block with the BSN value now assigned to 
ARQ_TX_WINDOW_START, the value of ARQ_TX_WINDOW_START shall be incremented until an BSN 
value is reached for which no acknowledgment has been received. 

A bitmap entry not indicating acknowledgement shall be considered a NACK for the corresponding blocks. 

When a cumulative with selective acknowledgment and a valid BSN is received, the transmitter performs 
the actions described above for cumulative acknowledgment, followed by those for a selective 
acknowledgment. 

All timers associated with acknowledged blocks shall be cancelled. 
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A Discard message shall be sent following violation of ARQ_BLOCK_LIFETIME. The message may be sent 
immediately or may be delayed up to ARQ_RX_PURGE_T1ME0UT + ARQ_RETRY_TIMEOUT. Following 
the first transmission, subsequent discard orders shall be sent to the receiver at intervals of 
ARQ_RETRYJT1 MEOUT until an acknowledgment to the discarded BSN has been received. Discard orders 
for adjacent BSN values may be accumulated in a single Discard message. 

The actions to be taken by the transmitter state machine when it wants to initiate a reset of the receiver ARQ 
state machine are provided in Figure 34. The actions to be taken by the transmitter state machine when an 
ARQ Reset message is received are also provided in Figure 34. 
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transmission 
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ARQ Reset 
Type = 0x0 



Set T22 



Wait for 
ARQ Reset 
Type = 0x1 



Timeout T22 




ARQ Reset 
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Clear T22 



ARQ_ 
TX_WINDOW_ 
START = 0 



Discard SDUs with 
blocks in 
Discarded state 



Enable 
transmission 



ARQ Reset 
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Disable 
reception 



ARQ_ 
RX_WINDOW_ 
START= 0 



Discard all 
incomplete SDUs 



Deliver all 
complete SDUs 



Enable reception 



Send 
ARQ Reset 
Type = 0x1 

f End- I 
I ARQ Reset J 



End 
ARQ Reset 



Figure 34— ARQ Reset message dialog— transmitter initiated 



Synchronization of the ARQ state machines is governed by a timer managed by the transmitter state 
machine. Each time ARQ_TX_WINDOW_START is updated, the timer is set to zero. When the timer exceeds 
the value of ARQ_SYNC_LOSSjriMEOUT, the transmitter state machine shall initiate a reset of the 
connection's state machines as described in Figure 35. 
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Transmitter 
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Send 
ARQ Reset 
Type = 0x0 
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ARQ Reset 
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Timeout T22 
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complete SDUs 



Enable reception 



Send 
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Type = 0x2 



End 
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Figure 35— ARQ Reset message dialog— receiver initiated 



A Discard message may be sent to the receiver when the transmitter wants to skip ARQ blocks up to the 
BSN value specified in the Discard message. Upon receipt of the message, the receiver updates its state 
information to indicate the specified blocks were received and forwards the information to the transmitter 
through an ARQ Feedback IE at the appropriate time. 
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6.3.4.6.3 Receiver state machine 



When a PDU is received, its integrity is determined based on the CRC-32 checksum. If a PDU passes the 
checksum, it is unpacked and de-fragmented, if necessary. The receiver maintains a sliding-window defined 
by ARQ_RX_MNDOW_START state variable and the ARQ_WINDOW_SIZE parameter. When an ARQ 
block with a number that falls in the range defined by the sliding window is received, the receiver shall 
accept it. ARQ block numbers outside the sliding window shall be rejected as out of order. The receiver 
should discard duplicate ARQ blocks (i.e., ARQ blocks that where already received correctly) within the 
window. 




Add BSN to list of 
BSNs tobeACKed 




Block \ No 
.duplicated? y 




ARQ_RX_HIGHEST_BSN 
o BSN + 1 



Reset Timer 
ARQ_RX_PURGE_TIMEOUT 
for this BSN 




Update 

ARQ_RX_WI N DOW_START 



(Re)Set Timer 
ARQ_RX_PU RG E_TIM EOUT 
for this BSN 



T 



J 



Reset Timer 
ARQ_SYNC_LOSS_TIMEOUT 



Discard 
block 



c 



Store 
block 



Done 



J 



Figure 36 — ARQ block reception 



The sliding window is maintained such that the ARQ_RX_WINDOW_START variable always points to the 
lowest numbered ARQ block that has not been received or has been received with errors. When an ARQ 
block with a number corresponding to the ARQ_RX_WINDOW_START is received, the window is advanced 
(i.e., ARQ_RX_WINDOW_START is incremented modulo ARQ_BSN_MOD ULUS) such that the 
ARQ_RX_WINDOW_START variable points to the next lowest numbered ARQ block that has not been 
received or has been received with errors. The timer associated with ARQ_SYNC_LOSS_TIMEOUT shall be 
reset. 

As each block is received, a timer is started for that block. When the value of the timer for a block exceeds 
AR Q_RX_PURGE_TIMEO UT, the timeout condition is marked. When the timeout condition is marked, 
ARQ_RX_WINDOW_START is advanced to the BSN of the next block not yet received after the marked 
block. Timers for delivered blocks remain active and are monitored for timeout until the BSN values are 
outside the receive window. 
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When ARQ_RXJWINDOW_START is advanced, any BSN values corresponding to blocks that have not yet 
been received residing in the interval between the previous and current ARQ_RXJWINDOW_START value 
shall be marked as received and the receiver shall send an ARQ Feedback IE to the transmitter with the 
updated information. Any blocks belonging to complete SDUs shall be delivered. Blocks from partial SDUs 
shall be discarded. 

When a discard message is received from the transmitter, the receiver shall discard the specified blocks, 
advance ARQ_RX_WINDOW_START to the BSN of the first block not yet received after the BSN provided 
in the Discard message, and mark all not received blocks in the interval from the previous to new 
ARQ_RX_W1ND0W_START values as received for ARQ feedback IE reporting. 

For each ARQ block received, an acknowledgment shall be sent to the transmitter. Acknowledgment for 
blocks outside the sliding window shall be cumulative. Acknowledgments for blocks within the sliding 
window may be either for specific ARQ blocks (i.e., contain information on the acknowledged ARQ block 
numbers), or cumulative (i.e., contain the highest ARQ block number below which all ARQ blocks have 
been received correctly) or a combination of both (i.e., cumulative with selective). Acknowledgments shall 
be sent in the order of the ARQ block numbers they acknowledge. The frequency of acknowledgment 
generation is not specified here and is implementation dependent. 

A MAC SDU is ready to be handed to the upper layers when all of the ARQ blocks of the MAC SDU have 
been correctly received within the time-out values defined. 

When ARQ_DELIVER_IN_ORDER is enabled, a MAC SDU is handed to the upper layers as soon as all the 
ARQ blocks of the MAC SDU have been correctly received within the defined time-out values and all 
blocks with sequence numbers smaller than those of the completed message have either been discarded due 
to time-out violation or delivered to the upper layers. 

When ARQ_DELIVERJN_ORDER is not enabled, MAC SDUs are handed to the upper layers as soon as all 
blocks of the MAC SDU have been successfully received within the defined time-out values. 

The actions to be taken by the receiver state machine when an ARQ Reset message is received are provided 
in Figure 34. The actions to be taken by the receiver state machine when it wants to initiate a reset of the 
transmitter ARQ state machine are provided in Figure 35. 

Synchronization of the ARQ state machines is governed by a timer managed by the receiver state machine. 
Each time ARQ_RX_WINDOW_START is updated, the timer is set to zero. When the timer exceeds the value 
of ARQ_SYNC_LOSSJTIMEOUT the receiver state machine shall initiate a reset of the connection's state 
machines as described in Figure 35. 

6.3.5 Scheduling services 

Scheduling services represent the data handling mechanisms supported by the MAC scheduler for data 
transport on a connection. Each connection is associated with a single data service. Each data service is 
associated with a set of QoS parameters that quantify aspects of its behavior. These parameters are managed 
using the DSA and DSC message dialogs. Four services (11.13.11) are supported: Unsolicited Grant Service 
(UGS), Real-time Polling Service (HPS), Non-real-time Polling Service (nrtPS), and Best Effort (BE). The 
following text provides a brief description of each of the supported scheduling services, including the 
mandatory QoS parameters that shall be included in the service flow definition when the scheduling service 
is enabled for a service flow. A detailed description of each QoS parameter is provided in 11.13. 

The UGS is designed to support real-time data streams consisting of fixed-size data packets issued at 
periodic intervals, such as Tl/El and Voice over IP without silence suppression. The mandatory QoS service 
flow parameters for this scheduling service are Maximum Sustained Traffic Rate (11.13.6), Maximum 
Latency (11.13.14), Tolerated Jitter (11.13.13), and Request/Transmission Policy (11.13.12). If present, the 
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Minimum Reserved Traffic Rate parameter (11.13.8) shall have the same value as the Maximum Sustained 
Traffic Rate parameter. 

The rtPS is designed to support real-time data streams consisting of variable-sized data packets that are 
issued at periodic intervals, such as moving pictures experts group (MPEG) video. The mandatory QoS 
service flow parameters for this scheduling service are Minimum Reserved Traffic Rate (11.13.8), 
Maximum Sustained Traffic Rate (11.13.6), Maximum Latency (11.13.14), and Request/Transmission 
Policy (11.13.12). 

The nrtPS is designed to support delay-tolerant data streams consisting of variable-sized data packets for 
which a minimum data rate is required, such as FTP. The mandatory QoS service flow parameters for this 
scheduling service are Minimum Reserved Traffic Rate (11.13.8), Maximum Sustained Traffic Rate 
(11.13.6), Traffic Priority (11.13.5), and Request/Transmission Policy (11.13.12). 

The BE service is designed to support data streams for which no minimum service level is required and 
therefore may be handled on a space-available basis. The mandatory QoS service flow parameters for this 
scheduling service are Maximum Sustained Traffic Rate (11.13.6), Traffic Priority (11.13.5), and Request/ 
Transmission Policy (11.13.12). 

6.3.5.1 Outbound transmission scheduling 

Outbound transmission scheduling selects the data for transmission in a particular frame/bandwidth 
allocation and is performed by the BS for downlink, and SS for uplink. In addition to whatever other factors 
the scheduler may deem pertinent, the following items are taken into account for each active service flow: 

— The scheduling service specified for the service flow. 

— The values assigned to the service flow's QoS parameters. 

— The availability of data for transmission. 

— The capacity of the granted bandwidth. 

6.3.5.2 Uplink request/grant scheduling 

Uplink request/grant scheduling is performed by the BS with the intent of providing each subordinate SS 
with bandwidth for uplink transmissions or opportunities to request bandwidth. By specifying a scheduling 
service and its associated QoS parameters, the BS scheduler can anticipate the throughput and latency needs 
of the uplink traffic and provide polls and/or grants at the appropriate times. 

Table 112 summarizes the scheduling services and the poll/grant options available for each. The following 
subclauses define service flow scheduling services for uplink operations. 



Table 112— Scheduling services and usage rules 



Scheduling 
type 


PiggyBack 
Request 


Bandwidth 
stealing 


Polling 


UGS 


Not allowed 


Not allowed 


PM bit is used to request a unicast poll for bandwidth 
needs of non-UGS connections. 


rtPS 


Allowed 


Allowed 


Scheduling only allows unicast polling. 


nrtPS 


Allowed 


Allowed 


Scheduling may restrict a service flow to unicast 
polling via the transmission/request policy; otherwise 
all forms of polling are allowed. 


BE 


Allowed 


Allowed 


All forms of polling allowed. 
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6.3.5.2.1 UGS 

The UGS is designed to support real-time service flows that generate fixed-size data packets on a periodic 
basis, such as Tl/El and Voice over IP without silence suppression. The service offers fixed- size grants on a 
real-time periodic basis, which eliminate the overhead and latency of SS requests and assure that grants are 
available to meet the flow's real-time needs. The BS shall provide Data Grant Burst IEs to the SS at periodic 
intervals based upon the Maximum Sustained Traffic Rate of the service flow. The size of these grants shall 
be sufficient to hold the fixed-length data associated with the service flow (with associated generic MAC 
header and Grant management subheader) but may be larger at the discretion of the BS scheduler. In order 
for this service to work correctly, the Request/Transmission Policy (see 11.13.12) setting shall be such that 
the SS is prohibited from using any contention request opportunities for this connection. The key service IEs 
are the Maximum Sustained Traffic, Maximum Latency, the Tolerated Jitter, and the Request/Transmission 
Policy. If present, the Minimum Reserved Traffic Rate parameter shall have the same value as the Maximum 
Sustained Traffic Rate parameter. 

The Grant Management subheader (6.3.2.2.2) is used to pass status information from the SS to the BS 
regarding the state of the UGS service flow. The most significant bit of the Grant Management field is the 
Slip Indicator (SI) bit. The SS shall set this flag once it detects that this service flow has exceeded its 
transmit queue depth. Once the SS detects that the service flow's transmit queue is back within limits, it shall 
clear the SI flag. The flag allows the BS to provide for long term compensation for conditions, such as lost 
maps or clock rate mismatches, by issuing additional grants. The poll-me (PM) bit (6.3.6.3.3) may be used to 
request to be polled for a different, non-UGS connection. 

The BS shall not allocate more bandwidth than the Maximum Sustained Traffic Rate parameter of the Active 
QoS Parameter Set, excluding the case when the SI bit of the Grant Management field is set. In this case, the 
BS may grant up to 1% additional bandwidth for clock rate mismatch compensation. 

6.3.5.2.2 rtPS 

The rtPS is designed to support real-time service flows that generate variable size data packets on a periodic 
basis, such as moving pictures experts group (MPEG) video. The service offers real-time, periodic, unicast 
request opportunities, which meet the flow's real-time needs and allow the SS to specify the size of the 
desired grant. This service requires more request overhead than UGS, but supports variable grant sizes for 
optimum data transport efficiency. 

The BS shall provide periodic unicast request opportunities. In order for this service to work correctly, the 
Request/Transmission Policy setting (see 11.13.12) shall be such that the SS is prohibited from using any 
contention request opportunities for that connection. The BS may issue unicast request opportunities as 
prescribed by this service even if prior requests are currently unfulfilled. This results in the SS using only 
unicast request opportunities in order to obtain uplink transmission opportunities (the SS could still use 
unsolicited Data Grant Burst Types for uplink transmission as well). All other bits of the Request/Transmis- 
sion Policy are irrelevant to the fundamental operation of this scheduling service and should be set according 
to network policy. The key service IEs are the Maximum Sustained Traffic Rate, the Minimum Reserved 
Traffic Rate, the Maximum Latency and the Request/Transmission Policy. 

6.3.5.2.3 nrtPS 

The nrtPS offers unicast polls on a regular basis, which assures that the service flow receives request 
opportunities even during network congestion. The BS typically polls nrtPS CIDs on an interval on the order 
of one second or less. 

The BS shall provide timely unicast request opportunities. In order for this service to work correctly, the 
Request/Transmission Policy setting (see 11.13.12) shall be set such that the SS is allowed to use contention 
request opportunities. This results in the SS using contention request opportunities as well as unicast request 
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opportunities and unsolicited Data Grant Burst Types. All other bits of the Request/Transmission Policy are 
irrelevant to the fundamental operation of this scheduling service and should be set according to network 
policy. 

6.3.5.2.4 BE service 

The intent of the BE service is to provide efficient service for best effort traffic. In order for this service to 
work correctly, the Request/Transmission Policy setting shall be set such that the SS is allowed to use 
contention request opportunities. This results in the SS using contention request opportunities as well as 
unicast request opportunities and unsolicited Data Grant Burst Types. All other bits of the Request/ 
Transmission Policy are irrelevant to the fundamental operation of this scheduling service and should be set 
according to network policy. 

6.3.6 Bandwidth allocation and request mechanisms 

Note that during network entry and initialization every SS is assigned up to three dedicated CIDs for the 
purpose of sending and receiving control messages. These connection pairs are used to allow differentiated 
levels of QoS to be applied to the different connections carrying MAC management traffic. Increasing (or 
decreasing) bandwidth requirements is necessary for all services except incompressible constant bit rate 
UGS connections. The needs of incompressible UGS connections do not change between connection 
establishment and termination. The requirements of compressible UGS connections, such as channelized Tl, 
may increase or decrease depending on traffic. Demand Assigned Multiple Access (DAM A) services are 
given resources on a demand assignment basis, as the need arises. 

When an SS needs to ask for bandwidth on a connection with BE scheduling service, it sends a message to 
the BS containing the immediate requirements of the DAMA connection. QoS for the connection was 
established at connection establishment and is looked up by the BS. 

There are numerous methods by which the SS can get the bandwidth request message to the BS. The 
methods are listed in 6.3.6.1 through 6.3.6.6. 

6.3.6.1 Requests 

Requests refer to the mechanism that SSs use to indicate to the BS that they need uplink bandwidth 
allocation. A Request may come as a stand-alone bandwidth request header or it may come as a PiggyBack 
Request (see 6.3.2.2.2). The capability of Piggyback Request is optional. 

Because the uplink burst profile can change dynamically, all requests for bandwidth shall be made in terms 
of the number of bytes needed to carry the MAC header and payload, but not the PHY overhead. The 
Bandwidth Request message may be transmitted during any uplink allocation, except during any initial 
ranging interval. 

Bandwidth Requests may be incremental or aggregate. When the BS receives an incremental Bandwidth 
Request, it shall add the quantity of bandwidth requested to its current perception of the bandwidth needs of 
the connection. When the BS receives an aggregate Bandwidth Request, it shall replace its perception of the 
bandwidth needs of the connection with the quantity of bandwidth requested. The Type field in the 
bandwidth request header indicates whether the request is incremental or aggregate. Since Piggybacked 
Bandwidth Requests do not have a type field, Piggybacked Bandwidth Requests shall always be 
incremental. The self-correcting nature of the request/grant protocol requires that SSs shall periodically use 
aggregate Bandwidth Requests. The period may be a function of the QoS of a service and of the link quality. 
Due to the possibility of collisions, Bandwidth Requests transmitted in broadcast or multicast Request IEs 
should be aggregate requests. 
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Additional bandwidth request mechanisms include the focused bandwidth requests (see 6.3.6.4) and CDMA 
bandwidth requests (see 6.3.6.5). 

6.3.6.2 Grants 

For an SS, bandwidth requests reference individual connections while each bandwidth grant is addressed to 
the SS's Basic CID, not to individual CIDs. Since it is nondeterministic which request is being honored, 
when the SS receives a shorter transmission opportunity than expected (scheduler decision, request message 
lost, etc.), no explicit reason is given. In all cases, based on the latest information received from the BS and 
the status of the request, the SS may decide to perform backoff and request again or to discard the SDU. 

An SS may use Request IEs that are broadcast, directed at a multicast polling group it is a member of, or 
directed at its Basic CID. In all cases, the Request IE burst profile is used, even if the BS is capable of 
receiving the SS with a more efficient burst profile. To take advantage of a more efficient burst profile, the 
SS should transmit in an interval defined by a Data Grant IE directed at its Basic CID. Because of this, 
unicast polling of an SS would normally be done by allocating a Data Grant IE directed at its Basic CID. 
Also note that, in a Data Grant IE directed at its Basic CID, the SS may make bandwidth requests for any of 
its connections. 

The procedure followed by SSs is shown in Figure 37. 

6.3.6.3 Polling 

Polling is the process by which the BS allocates to the SSs bandwidth specifically for the purpose of making 
bandwidth requests. These allocations may be to individual SSs or to groups of SSs. Allocations to groups of 
connections and/or SSs actually define bandwidth request contention IEs. The allocations are not in the form 
of an explicit message, but are contained as a series of IEs within the UL-MAP. 

Note that polling is done on SS basis. Bandwidth is always requested on a CID basis and bandwidth is 
allocated on an SS basis. 

6.3.6.3.1 Unicast 

When an SS is polled individually, no explicit message is transmitted to poll the SS. Rather, the SS is 
allocated, in the UL-MAP, bandwidth sufficient to respond with a Bandwidth (BW) Request. If the SS does 
not need bandwidth, the allocation is padded in accordance with 6.3.3.7. SSs that have an active UGS 
connection of sufficient bandwidth shall not be polled individually unless they set the PM bit in the header 
of a packet on the UGS connection. This saves bandwidth over polling all SSs individually. Note that unicast 
polling would normally be done on a per-SS basis by allocating a Data Grant IE directed at its Basic CID: 
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NOTE — The SS local scheduler decides which connections get the granted bandwidth. 

Figure 37— SS Request/Grant flow chart 
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The information exchange sequence for individual polling is shown in Figure 38. 
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Figure 38— Unicast polling 



6.3.6.3.2 Multicast and broadcast 

If insufficient bandwidth is available to individually poll many inactive SSs, some SSs may be polled in 
multicast groups or a broadcast poll may be issued. Certain CIDs are reserved for multicast groups and for 
broadcast messages, as described in Table 345. As with individual polling, the poll is not an explicit 
message, but bandwidth allocated in the UL-MAP. The difference is that, rather than associating allocated 
bandwidth with an SS's Basic CID, the allocation is to a multicast or broadcast CID. An example is provided 
in Table 113. 
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The information exchange sequence for multicast and broadcast polling is shown in Figure 39. 

When the poll is directed at a multicast or broadcast CID, an SS belonging to the polled group may request 
bandwidth during any request interval allocated to that CID in the UL-MAP by a Request IE. In order to 
reduce the likelihood of collision with multicast and broadcast polling, only SS's needing bandwidth reply; 
they shall apply the contention resolution algorithm as defined in 6.3.8 to select the slot in which to transmit 
the initial bandwidth request. Zero-length bandwidth (BW) requests shall not be used in multicast or 
broadcast Request Intervals. 

The SS shall assume that the transmission has been unsuccessful if no grant has been received in the number 
of subsequent UL-MAP messages specified by the parameter Contention-based reservation timeout (see 
11.3.1). Note that, with a frame-based PHY with UL-MAPs occurring at predetermined instants, erroneous 
UL-MAPs may be counted towards this number. If the rerequest is made in a multicast or broadcast 
opportunity, the SS continues to run the contention resolution algorithm in 6.3.8. Note that the SS is not 
restricted to issuing the rerequest in a multicast or broadcast Request Interval. 



Table 113 — Sample UL-MAP with multicast and broadcast IE for SC and SCa 





UL-MAP IE fields 


Interval description 


CID 


UIUC 


Offset 




(16 bits) 


(4 bits) 


(12 bits) 


Initial Ranging 


0000 


2 


0 


Multicast group 0xFFC5 Bandwidth Request 


0xFFC5 


1 


405 


Multicast group OxFFDA Bandwidth Request 


OxFFDA 


1 


605 


Broadcast Bandwidth Request 


OxFFFF 


1 


805 


SS 5 Uplink Grant 


0x007B 


4 


961 


SS 21 Uplink Grant 


0x01C9 


7 


1136 


* 


* 


* 


* 
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* 
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* 
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* ! 


* 


* 
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Figure 39— Multicast and broadcast polling 



6.3.6.3.3 PM bit 



SSs with currently active UGS connections may set the PM bit [bit PM in the Grant Management subheader 
(6.3.2.2.2)] in a MAC packet of the UGS connection to indicate to the BS that they need to be polled to 
request bandwidth for non-UGS connections. To reduce the bandwidth requirements of individual polling, 
SSs with active UGS connections need be individually polled only if the PM bit is set (or if the interval of 
the UGS is too long to satisfy the QoS of the SS's other connections). Once the BS detects this request for 
polling, the process for individual polling is used to satisfy the request. The procedure by which an SS 
stimulates the BS to poll it is shown in Figure 40. To minimize the risk of the BS missing the PM bit, the SS 
may set the bit in all UGS MAC Grant Management subheaders in the uplink scheduling interval. 
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Figure 40— PM bit usage 

6.3.6.4 Contention-based focused Bandwidth Requests for WirelessMAN-OFDM 

The WirelessMAN-OFDM PHY supports two contention-based Bandwidth Request mechanisms. The 
mandatory mechanism allows the SS to send the bandwidth request header as specified in 6.3.6.1 during a 
REQ Region-Full. Alternatively, the SS may send a Focused Contention Transmission during a REQ 
Region-Focused. This transmission consists of a Contention Code modulated on a Contention Channel 
consisting of four carriers. The selection of the Contention Code is done with equal probability among the 
eight possible codes. The selection of the Contention Channel is done with equal probability among the 
time/frequency transmit opportunities applicable to the SS. Upon detection, the BS shall provide an uplink 
allocation for the SS to transmit a Bandwidth Request MAC PDU and optionally additional data, but instead 
of indicating a Basic CID, the broadcast CID shall be sent in combination with an OFDM 
Focused_Contention_IE, which specifies the Contention Channel, Contention Code, and Transmit 
Opportunity that were used by the SS. This allows an SS to determine whether it has been given an 
allocation by matching these parameters with the parameters it used. See also 8.3.7.3.3. 

6.3.6.5 Contention-based CDMA Bandwidth Requests for WirelessMAN-OFDM A 

The WirelessMAN-OFDMA PHY supports two mandatory contention-based Bandwidth Request 
mechanisms: the SS shall either send the bandwidth request header as specified in 6.3.6.1, or use the 
CDMA-based mechanism as specified in the following paragraphs of this subclause. 

As specified in 6.3.10.3, the OFDMA-based PHY specifies a Ranging Subchannel and a subset of Ranging 
codes that shall be used for contention-based Bandwidth Requests. The SS, upon needing to request 
bandwidth, shall select, with equal probability, a Ranging Code from the code subset allocated to Bandwidth 
Requests. This Ranging Code shall be modulated onto the Ranging Subchannel and transmitted during the 
appropriate uplink allocation. 

Upon detection, the BS shall provide (an implementation dependent) uplink allocation for the SS, but 
instead of indicating a Basic CID, the broadcast CID shall be sent in combination with a 
CDMA_Allocation_IE, which specifies the transmit region and Ranging Code that were used by the SS. 
This allows an SS to determine whether it has been given an allocation by matching these parameters with 
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the parameters it used. The SS shall use the allocation to transmit a Bandwidth Request MAC PDU and/or 
data. The SS may only omit the Bandwidth Request PDU when the BS indicated so in the 
CDMA_Allocation_IE (see Table 290). 

If the BS does not issue the uplink allocation described above, or the Bandwidth Request MAC PDU does 
not result in a subsequent allocation of any bandwidth, the SS shall assume that the Ranging Code 
transmission resulted in a collision and follow the contention resolution as specified in 6.3.8. 

6.3.6.6 Optional Mesh topology support 

The WirelessHUMAN system provides optional support for Mesh topology. Unlike the PMP mode, there are 
no clearly separate downlink and uplink subframes in the Mesh mode. Each station is able to create direct 
communication links to a number of other stations in the network instead of communicating only with a BS. 
However, in typical installations, there will still be certain nodes that provide the BS function of connecting 
the Mesh network to the backhaul links. In fact, when using Mesh centralized scheduling (described below), 
these BS nodes perform much of the same basic functions as do the BS in PMP mode. Thus, the key 
difference is that in Mesh mode all the SSs may have a direct links with other SSs. Further, there is no need 
to have direct link from an SS to the BS of the Mesh network. This connection can be provided via other 
SSs. Communication in all these links shall be controlled by a centralized algorithm (either by the BS or 
"decentralized" by all nodes periodically), scheduled in a distributed manner within each node's extended 
neighborhood, or scheduled using a combination of these. 

6.3.6.6.1 Distributed scheduling 

The stations that have direct links are called neighbors and shall form a neighborhood. A node's neighbors 
are considered to be "one hop" away from the node. A two-hop extended neighborhood contains, 
additionally, all the neighbors of the neighborhood. In the coordinated distributed scheduling mode, all the 
stations (BS and SSs) shall coordinate their transmissions in their extended two-hop neighborhood. 

The coordinated distributed scheduling mode uses some or the entire control portion of each frame to 
regularly transmit its own schedule and proposed schedule changes on a PMP basis to all its neighbors. 
Within a given channel all neighbor stations receive the same schedule transmissions. All the stations in a 
network shall use this same channel to transmit schedule information in a format of specific resource 
requests and grants. 

Coordinated distributed scheduling ensures that transmissions are scheduled in a manner that does not rely 
on the operation of a BS, and that are not necessarily directed to or from the BS. 

Within the constraints of the coordinated schedules (distributed or centralized), uncoordinated distributed 
scheduling can be used for fast, ad-hoc setup of schedules on a link-by- link basis. Uncoordinated distributed 
schedules are established by directed requests and grants between two nodes, and shall be scheduled to 
ensure that the resulting data transmissions (and the request and grant packets themselves) do not cause 
collisions with the data and control traffic scheduled by the coordinated distributed nor the centralized 
scheduling methods. 

Both the coordinated and uncoordinated distributed scheduling employ a three-way handshake. 

— MSH-DSCH: Request is made along with MSH-DSCH:Avalabilities, which indicate potential slots 
for replies and actual schedule. 

— MSH-DSCH: Grant is sent in response indicating a subset of the suggested availabilities that fits, if 
possible, the request. The neighbors of this node not involved in this schedule shall assume the 
transmission takes place as granted. 
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— MSH-DSCH:Grant is sent by the original requester containing a copy of the grant from the other 
party, to confirm the schedule to the other party. The neighbors of this node not involved in this 
schedule shall assume the transmission takes place as granted. 

The differences between coordinated and uncoordinated distributed scheduling are as follows: In the 
coordinated case, the MSH-DSCH messages are scheduled in the control subframe in a collision free 
manner; whereas, in the uncoordinated case, MSH-DSCH messages may collide. Nodes responding to a 
Request should, in the uncoordinated case, wait a sufficient number of minislots of the indicated 
Availabilities before responding with a grant, such that nodes listed earlier in the Request have an 
opportunity to respond. The Grant confirmation is sent in the minislots immediately following the first 
successful reception of an associated Grant packet. 

6.3.6.6.2 Centralized scheduling 

The schedule using centralized scheduling is determined in more of a centralized manner than in the 
distributed scheduling mode. 

The network connections and topology are the same as in the distributed scheduling mode described in 
6.3.6.6.1, but the scheduled transmissions for the SSs shall be defined by the BS. The BS determines the 
flow assignments from the resource requests from the SSs. Subsequently, the SSs determine the actual 
schedule from these flow assignments by using a common algorithm that divides the frame proportionally to 
the assignments. Thus, the BS acts just like the BS in a PMP network except that not all of the SSs have to 
be directly connected to the BS, and the assignments determined by the BS extends to those SSs not directly 
connected to the BS. The SS resource requests and the BS assignments are both transmitted during the 
control portion of the frame. 

Centralized scheduling ensures that transmissions are coordinated to ensure collision-free scheduling over 
the links in the routing tree to and from the BS, typically in a more optimal manner than the distributed 
scheduling method for traffic streams (or collections of traffic streams that share links), which persist over a 
duration that is greater than the cycle time io relay the new resource requests and distribute the updated 
schedule. 

A simple example of the use of the centralized scheduling flow-mechanism in MSH^CSCH is provided in 
Figure 42. The requested flows for the network are shown in Figure 41. For simplicity of notation, the data 
rate is assumed to be the burst profile number. 
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Figure 41— MSH-CSCF schedule example 
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The link fractions shown in Figure 42 are multiplied with (2 FlowSca,e Exponent+14) and with the ffame 
duration, then rounded up to the nearest duration of a whole number of minislots required to transmit this 
fraction (including preamble). 

Each node shall ensure that the duration of all resulting minislot allocations per channel does not exceed the 
available minislot space (in one or two frames depending on the Frame schedule flag) by reducing all 
allocations proportionally. Each node shall then recursively round down the number of minislots of the 
allocation with the smallest decimal fraction and add another minislot to the allocation with the largest 
decimal fraction. Before transmitting the schedule, the Mesh BS shall ensure that this computation does not 
result in nonzero allocations smaller than required to transmit a preamble and one data symbol. 
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Figure 42— MSH-CSCH flow usage example 



The number of frames during which the CSCH schedule is valid is limited by the number of frames it takes 
to aggregate and distribute the next schedule. 

Each node uses the newly received schedule to compute the following: 

— The time the node shall transmit this schedule (if eligible) for nodes further down the transmission 
tree. 

— The frame where the last node in the transmission tree will be receiving this schedule. 

— The original transmission time by the Mesh BS of this schedule. 

To compute this, the node uses the routing tree from the last MSH-CSCF messages as modified by the link 
updates of the last MSH-CSCH message (which dictates the size of MSH-CSCH messages) and the 
following steps: 



Step 1) The Mesh BS transmits first in a new frame. 

Step 2) Then, the eligible children of the Mesh BS (i.e., nodes with a hop count equals 1), ordered 
by their appearance in the routing tree, transmit. 

Step 3) Then, the eligible children of the nodes from Step 2) (i.e., nodes with a hop count that 
equals 2), also ordered by their appearance in the routing tree, transmit. 

Step 4) The process continue until all eligible nodes in the routing tree have transmitted. 

Nodes shall fragment their message if it does not fit entirely before the end of the control subframe and at 
least the preamble and one data symbol fit. All nodes are eligible to transmit the grant schedule, except those 
that have no children. If a node's order requires it to transmit immediately after receiving, a delay of 
MinCSForwardingDelay u.s is inserted. 
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Each node shall also compute the timing of the uplink requests. Uplink requests start in the last frame where 
a node received the previous schedule. All nodes are eligible to transmit requests, except the Mesh BS. The 
request transmission order is reverse in hopcount (i.e., largest hopcount first), but retains the transmission 
order as listed in the routing tree for nodes with the same hopcount. 

The time between the first frame in which a node sends the request schedule and the last frame where a node 
receives the new grant schedule marks the validity of the previous grant schedule. This validity time 
overrides the Frame schedule flag two frame usage at the end of the validity time. Note that MSH-CSCF 
messages may be sent after the last request is received and before the grant schedule is transmitted by the 
Mesh BS. 
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Figure 43— MSH-CSCH schedule validity 
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6.3.7 MAC support of PHY 

Several duplexing techniques are supported by the MAC protocol. The choice of duplexing technique may 
affect certain PHY parameters as well as impact the features that can be supported. 

6.3.7.1 FDD 

In an FDD system, the uplink and downlink channels are located on separate frequencies and the downlink 
data can be transmitted in bursts. A fixed duration frame is used for both uplink and downlink transmissions. 
This facilitates the use of different modulation types. It also allows simultaneous use of both full-duplex SSs 
(which can transmit and receive simultaneously) and optionally half-duplex SSs (which cannot). If half- 
duplex SSs are used, the bandwidth controller shall not allocate uplink bandwidth for a half-duplex SS at the 
same time that it is expected to receive data on the downlink channel, including allowance for the 
propagation delay, SS transmit/receive transition gap (SSTTG) and SS receive/transmit transition gap 
(SSRTG). 

Figure 44 describes the basics of the FDD mode of operation. The fact that the uplink and downlink 
channels utilize a fixed duration frame simplifies the bandwidth allocation algorithms. A full-duplex SS is 
capable of continuously listening to the downlink channel, while a half-duplex SS can listen to the downlink 
channel only when it is not transmitting in the uplink channel. 
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Figure 44— Example of Burst FDD bandwidth allocation 



6.3.7.2 TDD 

In the case of TDD, the uplink and downlink transmissions occur at different times and usually share the 
same frequency. A TDD frame (see Figure 45) has a fixed duration and contains one downlink and one 
uplink subframe. The frame is divided into an integer number of PSs, which help to partition the'bandwidth 
easily. The TDD framing is adaptive in that the bandwidth allocated to the downlink versus the uplink can 
vary. The split between uplink and downlink is a system parameter and is controlled at higher layers within 
the system. 



6.3.7.3 DL-MAP 



The DL-MAP message defines the usage of the downlink intervals for a burst mode PHY. 



6.3.7.4 UL-MAP 



The UL-MAP defines the uplink usage in terms of the offset of the burst relative to the Allocation Start Time 
(units PHY-specific). 

6.3.7.4.1 Uplink timing 

Uplink timing is referenced from the beginning of the downlink subframe. The Allocation Start Time in the 
UL-MAP is referenced from the start of the downlink subframe and may be such that the UL-MAP 
references some point in the current or a future frame (see 6.3.7.5). The SS shall always adjust its concept of 
uplink timing based upon the Timing Adjustments sent in the RNG-RSP messages. 
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Figure 45— TDD frame structure. 



6.3.7.4.2 Uplink allocations 

For the SC and SCa PHY layers, the uplink bandwidth allocation map (UL-MAP) uses units of minislots. 
The size of the minislot is specified as a function of PSs and is carried in the UCD for each uplink channel. 

For the OFDM and OFDMA PHY layers, the uplink bandwidth allocation map (UL-MAP) uses units of 
symbols and subchannels. 

6.3.7.4.3 Uplink interval definition 

All of the IEs defined in 6.3.7.4.3.1 through 6.3.7.4.3.5 shall be supported by conformant SSs. Conformant 
BS may use any of these IEs when creating a UL-MAP message. 

6.3.7.4.3.1 Request IE 

Via the Request IE, the BS specifies an uplink interval in which requests may be made for bandwidth for 
uplink data transmission. The character of this IE changes depending on the type of CID used in the IE. If 
broadcast or multicast, this is an invitation for SSs to contend for requests. If unicast, this is an invitation for 
a particular SS to request bandwidth. Unicasts may be used as part of a QoS scheduling scheme that is 
vendor dependent. For any uplink allocation, the SS may optionally decide to use the allocation for data or 
requests (or requests piggybacked in data). PDUs transmitted in this interval shall use the bandwidth request 
header format (see 6.3.2). 

For bandwidth request contention opportunities, the BS shall allocate a grant that is an integer multiple of 
the value of "Bandwidth request opportunity size," which shall be published in each UCD transmission. 
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6.3.7.4.3.2 Initial Ranging IE 

Via the Initial Ranging IE, the BS specifies an interval in which new stations may join the network. An 
interval, equivalent to the maximum round-trip propagation delay plus the transmission time of the RNG- 
REQ message, shall be provided in some UL-MAPs to allow new stations to perform initial ranging. Packets 
transmitted in this interval shall use the RNG-REQ MAC Management message format (see 6.3.2.3.5). 

For ranging contention opportunities, the BS shall allocate a grant that is an integer multiple of the value of 
"Ranging request opportunity size," which shall be published in each UCD transmission. 

6.3.7.4.3.3 Data Grant Burst Type lEs 

The Data Grant Burst Type IEs provide an opportunity for an SS to transmit one or more uplink PDUs. 
These IEs are issued either in response to a request from a station, or because of an administrative policy, 
such as unicast polling, providing some amount of bandwidth to a particular station. 

The number of Data Grant Types available is PHY specific. Each Data Grant Burst Type description is 
defined in the UCD message. 

6.3.7.4.3.4 End of map IE 

An end of map IE terminates all actual allocations in the IE list. It is used to determine the length of the last 
interval. 

6.3.7.4.3.5 Gap IE 

The Gap IE indicates pauses in uplink transmissions. An SS shall not transmit during a Gap IE. 
6.3.7.5 Map relevance and synchronization 

Timing information in the DL-MAP and UL-MAP is relative. The following time instants are used as a 
reference for timing information: 

— DL-MAP: The start of the first symbol (including the preamble if present) of the frame in which the 
message was transmitted. 

— UL-MAP: The start of the first symbol (including the preamble if present) of the frame in which the 
message was transmitted plus the value of the Allocation Start Time. 

Information in the DL-MAP pertains to the current frame (the frame in which the message was received). 
Information carried in the UL-MAP pertains to a time interval starting at the Allocation Start Time measured 
from the beginning of the current frame and ending after the last specified allocation. This timing holds for 
both the TDD and FDD variants of operation. The TDD variant is shown in Figure 46 and Figure 47. The 
FDD variant is shown in Figure 48 and Figure 49. 
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Figure 47— Minimum time relevance of DL-MAP and UL-MAP (TDD) 
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Figure 48— Maximum time relevance of DL-MAP and UL-MAP (FDD) 
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6.3.7.5.1 WirelessMAN-SC PHY 

Allocation Start Time shall be subject to the following limitations: For FDD, the minimum Allocation Start 
Time value shall be the round trip delay + T proCt and the maximum Allocation Start Time value is 7/(i.e., the 
beginning of the next frame). For TDD, the Allocation Start Time value shall be either the ATDD split or the 
ATDD split + T f . The allocation shall be within a single frame. 

6.3.7.5.2 WirelessMAN-SCa PHY 

The first burst appearing in the downlink portion of a frame shall be the frame control header. The FCH shall 
contain one DL-MAP message, one UL-MAP message for each associated uplink channel, and optionally, a 
DCD message and a UCD message for each associated uplink channel. The order of appearance of the 
messages in an FCH burst shall be DL-MAP, UL-MAP, DCD, and UCD. 

The first burst description appearing in a DL-MAP shall specify the start of the burst immediately following 
the FCH. 

Each UL-MAP shall describe the content of the uplink portion of a single frame. 
Allocation Start Time shall be subject to the following limitations: 

— Minimum value: Allocation Start Time > Tf 

— Maximum value: Allocation Start Time <2xTf 

6.3.7.5.3 WirelessMAN-OFDM PHY 

Allocation Start Time shall be subject to the following limitations: 

— For FDD, the minimum Allocation Start Time value shall be the round trip delay + T pr0Cy and the 
maximum Allocation Start Time value is 7y(i.e., the beginning of the next frame). 

— For TDD, the Allocation Start Time value shall be either the ATDD split, or the ATDD split + Tfi and 
the allocation shall be within a single frame. 
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6.3.7.5.4 WirelessMAN-OFDMA PHY 

Allocation Start Time shall be subject to the following limitations: 

— Minimum value: Allocation Start Time > Tf 

— Maximum value: Allocation Start Time <2xTf 

6.3.7.5.5 Optional Mesh mode 

Only TDD is supported in Mesh mode. Contrary to the basic PMP mode, there are no clearly separate 
downlink and uplink subframes in the Mesh mode. Stations shall transmit to each other either in scheduled 
channels or in random access channels as in PMP mode. The frame structure is described in 8.3.5.3. 

6.3.7.5.5.1 Physical neighborhood list 

All the basic functions like scheduling and network synchronization are based on the neighbor information 
that all the nodes in the Mesh network shall maintain. Each node (BS and SS) maintains a physical 
neighborhood list with each entry containing the following fields: 

MAC Address 

48-bit MAC address of the neighbor. 
Hop Count 

Indicates distance in hops of this neighbor from the present node. If a packet has been successfully 
received from this neighbor it is considered to be 1 hop away. 
Node Identifier 

16-bit number used to identify this node in a more efficient way in MSH-NCFG messages. 
XmtHoldoffTime 

The minimum number of MSH-NCFG transmit opportunities that no MSH-NCFG message 
transmission is expected from this node after Next Xmt Time (see 6.3.2.3.35 for detailed 
definition). 
Next Xmt Time 

The MSH-NCFG transmit opportunity(ies) when the next MSH-NCFG from this node is expected 
(see 6.3.2.3.35 for detailed definition). 
Reported Flag 

Set to TRUE if this Next Xmt Time has been reported by this node in a MSH-NCFG packet. Else 
set to FALSE. 

Synchronization hop count 

This counter is used to determine superiority between nodes when synchronizing the network. 
Nodes can be assigned as master time keepers, which are synchronized externally (for example, 
using GPS). These nodes transmit Synchronization hop count of 0. Nodes shall synchronize to 
nodes with lower synchronization hop count, or if counts are the same, to the node with the lower 
Node ID. 

6.3.7.5.5.2 Schedule relevance with distributed scheduling 

When using coordinated distributed scheduling all the stations in a network shall use the same channel to 
transmit schedule information in a format of specific resource requests and grants in MSH-DSCH messages. 
A station shall indicate its own schedule by transmitting a MSH-DSCH regularly. The MSH-DSCH 
messages shall be transmitted during the control portion of the frame. Relevance of the MSH-DSCH is 
variable and entirely up to the station. An example case is given in Figure 50, in which Schedule Frames = 
0x2 (8 frames) has been assumed. 

MSH-DSCH messages are transmitted regularly throughout the whole Mesh network to distribute nodes' 
schedules and (together with network configuration packets) provide network synchronization information. 
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Figure 50— Time relevance example of MSH-DSCH in distributed scheduling 

An SS that has a direct link to the BS shall synchronize to the BS while an SS that is at least two hops from 
the BS shall synchronize to its neighbor SSs that are closer to the BS. 

The control portion of every [Schedule Frames + 1] frames (see MSH-NCFG :Network Descriptor, 
6.3.2.3.35.3) is reserved for communication of MSH-NCFG and MSH-NENT packets. 

6.3.7.5.5.3 Schedule relevance with centralized scheduling 

When using centralized scheduling the BS shall act as a centralized scheduler for the SSs. Using centralized 
scheduling, the BS shall provide schedule configuration (MSH-CSCF) and assignments (MSH-CSCH) to all 
SSs. 

The validity of a MSH-CSCH schedule is computed by each node as specified in 6.3.6.6.2. The BS 
determines the assignments from the resource requests received from the SSs. Intermediate SSs are 
responsible for forwarding these requests for SSs (listed in the current routing tree as specified by the last 
MSH-CSCF modified by the last MSH-CSCH update) that are further from the BS (i.e., more hops from the 
BS) as needed. All the SSs shall listen and compute the schedule. Further, they shall forward the MSH- 
CSCH message to their neighbors that are further away from the BS. 

Additionally, as with distributed scheduling, the control portion of every [Schedule Frames + 1] frames (see 
MSH-NCFG:Network Descriptor, 6.3.2.3.35.3) is reserved for communication of MSH-NCFG and MSH- 
NENT packets. 
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Figure 51— Time relevance example of MSH-CSCH in centralized scheduling 



6.3.7.5.5.4 Mesh network synchronization 

Network configuration (MSH-NCFG) and network entry (MSH-NENT) packets provide a basic level of 
communication between nodes in different nearby networks whether from the same or different equipment 
vendors or wireless operators. These packets are used to synchronize both centralized and distributed control 
Mesh networks. 
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This communication is used to support basic configuration activities such as: synchronization between 
nearby networks used (i.e., for multiple, co-located BSs to synchronize their uplink and. downlink 
transmission periods), communication and coordination of channel usage by nearby networks, and discovery 
and basic network entry of new nodes. 

MSH-NCFG, MSH-NENT, and MSH-DSCH can assist a node in synchronizing to the start of frames. For 
these messages, the control subframe, which initiates each frame, is divided into transmit opportunities (see 
8.3.5.3). The first transmit opportunity in a network control subframe may only contain MSH-NENT 
messages, while the remainder MSH-CTRL-LEN-1 may only contain MSH-NCFG messages. In 
scheduling control subframes, the MSH-DSCH-NUM transmit opportunities assigned for MSH-DSCH 
messages come last in the control subframe. The MSH-NCFG messages also contain the number of its 
transmit opportunity, which allows nodes to easily calculate the start time of the frame. 

6.3.7.5.5.5 MSH-NCFG/MSH-NENT transmission timing 

MSH-NCFG and MSH-NENT packets are scheduled for transmission during control subframes. To ensure 
that all nearby nodes receive these transmissions, the channel used is cycled through the available channels 
in the band, with the channel selection being based on the Frame number. So, for frame number i, the 
channel is determined by the array lookup shown in Equation (9). 

NetConfigChannel=Logical channel list[(Frame Number / (Scheduling Frames • 4 + 1 ) )%Channels] (9) 

where the Logical channel List, Channels, and Scheduling Frames are derived from the MSH- 
NCFG:Network Descriptor (see 6.3.2.3.35.3). The location within frames, burst profile etc. of MSH-NCFG 
and MSH-NENT packets are described in 8.3.5.3. 

6.3.7.5.5.6 Scheduling next MSH-NCFG transmission 

During the current Xmt Time of a node (i.e., the time slot when a node transmits its MSH-NCFG packet), 
the node uses the following procedure to determine its Next Xmt Time: 

Order its physical neighbor table by the Next Xmt Time. 

For each entry of the neighbor table, add the node's Next Xmt Time to the node's Xmt Holdoff 
Time to arrive at the node's Earliest Subsequent Xmt Time. 

Set TempXmtTime equal to this node's advertised Xmt Holdoff Time added to the current Xmt 
Time. 

Set success equal to false. 

While success equals false do: 

Determine the eligible competing nodes, which is the set of all nodes in the physical-neighbor list 
with a Next Xmt Time eligibility interval that includes TempXmtTime or with an Earliest 
Subsequent Xmt Time equal to or smaller than TempXmtTime. 

Hold a Mesh Election among this set of eligible competing nodes and the local node using 
TempXmtTime and the list of the Node IDs of all eligible competing nodes as the input: 
MeshElection (TempXmtTime t MyNodeID f CompetingNodeIDsList [ ] ) 

If (this node does not win Mesh election) 

Set TempXmtTime equal to next MSH-NCFG opportunity. 

Else: 

Set success equal to true. 

Set the node's Next Xmt Time equal to TempXmtTime. 
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The Mesh Election procedure determines whether the local node is the winner for a specific TempXmtTime 
among all the competing nodes. It returns TRUE, if the local node wins, or otherwise FALSE. The algorithm 
works as follows: 

boolean MeshElection (uint32 XmtTime,uintl6 MyNodeID,uintl6 NodelDList [ ] )) { 
uint32 nbr_smear_val,smear_val 1 ,smear_val2; 
smear_vall =inline_smear(MyNodeID A XmtTime )); 
smear_val2 =inline_smear(MyNodeID +XmtTime ); 
For each Node ID nbrsNodelD in NodelDList Do { 

nbr_smear_val =inline_smear(nbrsNodeID A XmtTime )); 
if(nbr_smear_val >smear_vall ) { 
return FALSE;//This node loses. 

} 

else if(nbr_smear_val ==smear_vall ) { 
//1st tie-breaker. 

nbr_smear_val =inline_smear(nbrsNodeID +XmtTime ); 
if(nbr_smear_val >smear_val2 ) { 
return FALSE;//This node loses. 

} 

else if(nbr_smear_val ==smear_val2 ) { 

//If we still collide at this point Break the tie based on MacAdr 
if ((XmtTime is even &&(nbrsNodeID >MyNodeID))|| 

(XmtTime is odd &&(nbrsNodeID <MyNodeID ))) { 

return FALSE^/This node looses. 

} 

} 

} 

//This node won over this competing node 
}//End for all competing nodes 
//This node is winner,it won over all competing nodes, 
return TRUE; 
} 

// Convert a uniform 16-bit value to an uncorrected uniform 16-bit hash value, uses mixing. 

uint32 inline_smear(uintl6 val) { 
val +=(val «12); 
val A =(val »22); 
val +=(val «4); 
val A =(val »9); 
val +=(val «10); 
val A =(val »2); 
val +=(val «7); 
val A =(val »12); 
return(val); 

} 

6.3.7.5.5.7 Scheduling MSH-NENT messages 

The NetEntry scheduling protocol provides the upper-layer protocol an unreliable mechanism to access the 
NetEntry slot(s), so that new nodes, which are not yet fully-functional members of the network, can 
communicate with the fully-functional members of the network. 
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In the NetEntry slots, new nodes shall transmit MSH-NENT messages using the following two step 
procedure: 

1) The initial MSH-NENT packet with request IE is sent in a random, contention-based fashion in 
a free network entry transmission slot immediately following MSH-NENT transmission 
opportunity after the targeted sponsor sends a MSH-NCFG. with sponsored MAC address 
0x000000000000 

2) After the sponsor advertises the new nodes MAC Address in a MSH-NCFG message, the new 
node may send a MSH-NENT immediately following MSH-NENT transmission opportunity. 

A new node uses the algorithm specified by the following C-like pseudocode to access NetEntry 
transmission slots: 

/*Variable Definitions */ 

Pkt *MSH-NENT_MsgQ =NULL;//MSH-NENT Message queue 

uint SponsorsState =UNAVAILABLE;//SponsorsState and OthersState record the NetEntry 
uint OthersState =BUS Y; 

// Address in the MSH-NCFG packet form the sponsor or other nodes, 

// which can be used to determine the availability of the next NetEntry transmission opportunity 
//SponsorsState can be UNAVAILABLE,AVAILABLE and POLLING. 
//OthersState can be AVAILABLE and BUSY, 
uint OthersMaxMacAdr =0xFFFFFFFF; 
uint OthersMinMacAdr =0x00000000; 

void RecvOutgoingMSH-NENT_Msg (Pkt *MSH-NENT_Msg) { 
MSH-NENT_MsgQ->enqueue (MSH-NENT_Msg); 

} 

void RecvIncomingMSH-NCFG_Msg (Pkt *MSH-NCFG_Msg) { 
if (MSH-NCFG_Msg->sourceMacAdr ==sponsorsMacAdr) { 
switch (MSH-NCFG_Msg->NetEntry Address) 
{ 

case 0x000000000000:SponsorsState =AVAILABLE; break; 
case myMacAdr: SponsorsState =POLLING; break; 
default: break; 

} 

} else { 

switch (MSH-NCFG_Msg->NetEntry Address) 
{ 

case 0x000000000000:break; 
default:OthersState =BUSY; 

if (OthersMaxMacAdr <MSH-NCFG_Msg->NetEntry Address) 
OtherMaxMacAdr=MSH-NCFGJvIsg->NetEntry Address; 
if (OthersMinMacAdr >MSH-NCFG_Msg->NetEntry Address) 
OtherMinMacAdr =MSH-NCFG_Msg->NetEntryAddress; 

} 

} 

void NetworkControlSubframeStart () { 
boolean xmt =FALSE; 
if (MSH-NENT_MsgQ->qLength()) { 
if (SponsorsState ==AVAILABLE) { 
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if (OthersState !=BUSY) { 
xmt =TRUE; 

} 

} 

else if (SponsorsState ==POLLING) { 
if (OthersState !=BUSY) { 
xmt =TRUE; 

} 

else 
{ 

if (((mayMacAdr >OthersMaxMacAdr)&&(e ven supperframe))] | 
((mayMacAdr <OthersMinMacAdr)&&(odd supperframe))) { 
xmt =TRUE; 

} 

} 

} 

} 

if (xmt) { 

Pkt*MSH-NENT_Msg =MSH-NENT_MsgQ->getHead() ; 
MSH-NENT_MsgQ->dequeue(MSH-NENT_Msg); 
SendOutPkt (MSH-NENTJ4sg,nextNetEntryslot); 

} 

SponsorsState =UNAVAILABLE; 
OthersState =AVAILABLE; 
OthersMaxMacAdr =0x000000000000; 
OthersMinMacAdr =0xFFFFFFFFFFFF; 

} 

6.3.7.5.5.8 MSH-NCFG Reception Procedure 

When a MSH-NCFG packet is received from a neighbor, the following is performed: 

The hop count field in the Physical Neighborhood List (see 6.3.7.5.5.1) for the neighbor itself is set to 1. 
The hop count field for other nodes listed in the MSH-NCFG message is set to Hops to Neighbor 
+2 (see Table 66) unless they are already listed with a lower hop count 

The Next Xmt Time and Xmt Holdoff Time of the transmitting node and all reported nodes are updated. 

The "Reported Flag" for each entry in the Physical Neighbor Table that was modified is set to FALSE. 
6.3.7.6 Optional MAC AAS Support of WirelessMAN-SCa, OFDM, and OFDMA 
6.3.7.6.1 AAS MAC services 

AAS (see [B4], [B36], [B37], and [B3] for generic literature), through the use of more than one antenna 
element, can improve range and system capacity by adapting the antenna pattern and concentrating its 
radiation to each individual subscriber. The spectral efficiency can be increased linearly with the number of 
antenna elements. This is achieved by steering beams to multiple users simultaneously so as to realize an 
inter-cell frequency reuse of one and an in-cell reuse factor proportional to the number of antenna elements. 
An additional benefit is the signal-to-noise ratio (SNR) gain realized by coherently combining multiple 
signals, and the ability to direct this gain to particular users. Another possible benefit is the reduction in 
interference achieved by steering nulls in the direction of co-channel interferers. Combining the benefits of 
increasing the SNR of certain subscribers and steering nulls to others, enables bursts to be concurrently 
transmitted to spatially separated SSs. For the uplink direction the same principle can be applied in a 
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reciprocal fashion. A concurrent transmission of bursts does not necessarily increase the system's range but 
may enhance system capacity. 

Support mechanisms for AAS are specified, which allow a system to deliver the benefits of adaptive arrays 
while maintaining compatibility for non-AAS SSs. 

The design of the AAS option provides a mechanism to migrate from a non-AAS system to an AAS enabled 
system in which the initial replacement of the non-AAS capable BS by an AAS capable BS should cause the 
only service interruption to (non-AAS) SSs. 

This is achieved by dedicating part of the frame to non-AAS traffic and part to AAS traffic. The allocation is 
performed dynamically by the BS. Non-AAS SSs shall ignore AAS traffic, which they can identify based on 
the DL-MAP/UL-MAP messages. 

The AAS part of the DL frame begins with an AAS specific Preamble, see Figure 52 and Figure 53. 
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Figure 52— AAS Zone, FDD 
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Figure 53— AAS Zone, TDD 



For bandwidth request/allocation, AAS enabled SSs may use dedicated private DL-MAP/UL-MAP 
messages as well as tools specific for AAS (see specific PHY sections), which can be used to facilitate 
avoidance of collisions with non-AAS traffic. 

Special considerations apply to those parts of the frame that are not scheduled, e.g., initial-ranging and 
Bandwidth-request, as discussed in 6.3.7.6.3 and 6.3.7.6.6. 

6.3.7.6.2 MAC control functions 

The control of the AAS part of the frame may be done by unicasting private management messages to 
individual SSs. These messages shall be the same as the broadcast management messages, except that the 
basic CID assigned to the SS is used instead of the Broadcast CID. 

If AAS enabled SSs can decode the broadcast DL-MAP and DCD messages, the BS may specify concurrent 
bursts by means of the extended concurrent transmission IE format as described in 8.2.1.9.2.7, 8.2.1.9.3.5, 
and 8.3.6.2.6. 

6.3.7.6.3 AAS downlink synchronization 

When the SS first attempts to synchronize to the downlink transmission, the BS is unaware of its presence, 
and therefore is not aiming the adaptive array at its direction. Nevertheless, the frame start preamble is a 
repetitive well-known pattern, and SS may utilize the inherent processing gain associated with it in order to 
synchronize timing and frequency parameters with the BS. The BS may further employ active scanning or 
diversity methods to speed up and enhance the process of downlink synchronization. These methods are 
PHY-specific, and described in the respective PHY section. 

6.3.7.6.4 Alerting the BS about presence of a new SS in an AAS system 

In a non-AAS system, after synchronizing to the downlink, an SS attempts to obtain the downlink 
parameters by decoding the DL-MAP and DCD messages. In an AAS system, an SS may be able to obtain 
the downlink parameters if it receives the broadcast channel with enough energy so it can decode the DL- 
MAP and DCD messages. If this is the case, the SS can continue with the network entry process just like the 
non-AAS case, and the BS will get the chance to tune the adaptive array to it during the ranging process. 

Alternatively, an AAS SS may use the following procedure to alert the BS to its presence, so the BS can 
adapt its antenna array to the SS position. 
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An AAS BS may reserve a fixed, pre-defined part of the frame as initial-ranging contention slots for this 
alert procedure. The number of contention slots and their location in the frame is PHY specific (see 
8.2.1.9.3, 8.3.7.2, 8.4.4.2, respectively). These contention slots shall be called AAS-alert-slots. 

When an AAS SS has synchronized to the downlink, yet is unable to obtain the downlink parameters 
because it cannot decode the DL-MAP and DCD messages, it shall attempt initial ranging on the AAS-alert- 
slots. Unlike usual initial ranging, the SS shall use all available contention slots, in order to allow the BS 
adaptive array enough time and processing gain to shape the beam for it. After such an attempt the SS shall 
wait for a transmission containing DL-MAP and DCD messages from the BS, and shall continue the 
network entry process like a non-AAS SS. 

If the DL-MAP and DCD messages fail to arrive, the SS shall use an exponential backoff algorithm for 
selecting the next frame in which to attempt alerting the BS to its presence. The algorithm shall be the same 
as that used for initial ranging by non-AAS stations (see 6.3.8). 

6.3.7.6.5 FDD/TDD support 

Adaptive Arrays use channel state information in the PHY at both downlink and uplink. When channel state 
of the downlink is required at the BS, there are two ways to obtain it: 

— By relying on reciprocity, thus using the uplink channel state estimation as the downlink channel 
state. 

— By using feedback, thus transmitting the estimated channel state from the SS to BS. 

The first method is simpler and is well suited for TDD systems. The second method is more suitable for 
FDD systems, where reciprocity does not apply (due to the large frequency separation between uplink and 
downlink channels). The second method may also be used for TDD systems. 

Channel state information is obtained by using two MAC control messages: AAS-FBCK-REQ and AAS- 
FBCK-RSP (see 6.3.2.3.40). The request instructs the SS to measure, the results of which shall be returned 
in the response after the measurement period has ended. The BS shall provide an uplink allocation to enable 
the SS to transmit this response. Using FDD, the BS shall issue AAS-FBCK-REQ messages. Using TDD, 
the BS may issue AAS-FBCK messages. 

6.3.7.6.6 Requesting bandwidth 

AAS subscribers might not be able to request bandwidth using the usual contention mechanism. This 
happens because the adaptive array may not have a beam directed at the SS when it is requesting bandwidth, 
and the Bandwidth Request will be lost. In order to avoid this situation, an AAS SS is directed by the BS as 
to whether or not it may use broadcast allocations for requesting bandwidth. The BS may change its 
direction dynamically using the AAS broadcast permission TLV, which is carried by the RNG-RSP message. 
The SS shall signify by using the AAS broadcast capability TLV in the RNG_REQ message whether or not 
it can receive the broadcast messages. 

When an SS is directed not to use the broadcast CID to request bandwidth, it is the responsibility of the BS 
to provide a polling mechanism to learn about the SS bandwidth requirements. 

6.3.8 Contention resolution 

The BS controls assignments on the uplink channel through the UL-MAP messages and determines which 
minislots are subject to collisions. Collisions may occur during Initial Ranging and Request intervals 
defined by their respective IEs. The potential occurrence of collisions in Request Intervals is dependent on 
the CID in the respective IE. This subclause describes uplink transmission and contention resolution. For 
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simplicity, it refers to the decisions an SS makes. Since an SS can have multiple uplink service flows (each 
with its own CID), it makes these decisions on a per CID or per service QoS basis. 

The mandatory method of contention resolution that shall be supported is based on a truncated binary 
exponential backoff, with the initial backoff window and the maximum backoff window controlled by the 
BS The values are specified as part of the UCD message and represent a power-of-two value. For example, 
a value of 4 indicates a window between 0 and 15; a value of 10 indicates a window between 0 and 1023. 

When an SS has information to send and wants to enter the contention resolution process, it sets its internal 
backoff window equal to the Request (or Ranging for initial ranging) Backoff Start defined in the UCD 
message referenced by the UCD Count in the UL-MAP message currently in effect. 

The SS shall randomly select a number within its backoff window. This random value indicates the number 
of contention transmission opportunities that the SS shall defer before transmitting. An SS shall consider 
only contention transmission opportunities for which this transmission would have been eligible. These are 
defined by Request IEs (or Initial Ranging IEs for initial ranging) in the UL-MAP messages. Note that each 
IE may consist of multiple contention transmission opportunities. 

Using bandwidth requests as an example, consider an SS whose initial backoff window is 0 to 15 and 
assume it randomly selects the number 11. The SS must defer a total of 11 contention transmission 
opportunities. If the first available Request IE is for 6 requests, the SS does not use this and has 5 more 
opportunities to defer. If the next Request IE is for 2 requests, the SS has 3 more to defer. If the third Request 
IE is for 8 requests, the SS transmits on the fourth opportunity, after deferring for 3 more opportunities. 

After a contention transmission, the SS waits for a Data Grant Burst Type IE in a subsequent map (or waits 
for a RNG-RSP message for initial ranging). Once received, the contention resolution is complete. 

The SS shall consider the contention transmission lost if no data grant has been given within T16 (or no 
response within T3 for initial ranging). The SS shall now increase its backoff window by a factor of two, as 
long as it is less than the maximum backoff window. The SS shall randomly select a number within its new 
backoff window and repeat the deferring process described above. 

This retry process continues until the maximum number (i.e., Request Retries for bandwidth requests and 
Contention Ranging Retries for initial ranging) of retries has been reached. At this time, for bandwidth 
requests, the PDU shall be discarded. For initial ranging, proper actions are specified in 6.3.9.5. Note that 
the maximum number of retries is independent of the initial and maximum backoff windows that are defined 
by the BS. 

For bandwidth requests, if the SS receives a unicast Request IE or Data Grant Burst Type IE at any time 
while deferring for this CID, it shall stop the contention resolution process and use the explicit transmission 
opportunity. 

The BS has much flexibility in controlling the contention resolution. At one extreme, the BS may choose to 
set up the Request (or Ranging) Backoff Start and Request (or Ranging) Backoff End to emulate an 
Ethernet-style backoff with its associated simplicity and distributed nature as well as its fairness and 
efficiency issues. This would be done by setting Request (or Ranging) Backoff Start = 0 and Request (or 
Ranging) Backoff End = 10 in the UCD message. At the other end, the BS may make the Request (or 
Ranging) Backoff Start and Request (or Ranging) Backoff End identical and frequently update these values 
in the UCD message so that all SS are using the same, and hopefully optimal, backoff window. 



"Hie map currently in effect is the map whose allocation start time has occurred but which includes IEs that have not occurred. 
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6.3.8.1 Transmission opportunities 

A transmission opportunity is defined as an allocation provided in a UL-MAP or part thereof intended for a 
group of SSs authorized to transmit bandwidth requests or Initial Ranging requests. This group may include 
either all SSs having an intention to join the cell or all registered SSs or a multicast polling group. The 
number of transmission opportunities associated with a particular IE in a map is dependent on the total size 
of the allocation as well as the size of an individual transmission. 

The size of an individual transmission opportunity for each type of contention IE shall be published in each 
transmitted UCD message. The BS shall always allocate bandwidth for contention IEs in integer multiples 
of these published values. 

As an example, consider contention-based bandwidth requests for a WirelessMAN-SC system where the 
PHY protocol has a frame duration of 1 ms, 4 symbols for each PS, 2 PSs for each minislot, an uplink 
preamble of 16 symbols (i.e., 2 minislots), and an SS transition gap (SSTG) of 24 symbols (i.e., 3 minislots). 
Thus, assuming quadrature phase-shift keying (QPSK) modulation, each transmission opportunity requires 8 
minislots: 3 for the SSTG, 2 for the preamble, and 3 for the bandwidth request message. This pay load 
requirement would be specified as a value of 16 assigned to the UCD TLV "Bandwidth request opportunity 
size". 

If the BS schedules a Request IE of, for example, 24 minislots, there will be three transmission opportunities 
within this IE. Details of the three transmission opportunities are shown in Figure 54. 
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Figure 54— Example of Request IE containing multiple transmission opportunities 



6.3.9 Network entry and initialization 

Systems shall support the applicable procedures for entering and registering a new SS or a new node to the 
network. All network entry procedures described hereunder through and including 6.3.9.13 apply only to 
PMP operation. The network entry procedure for Mesh operation is described in 6.3.9.14. 

The procedure for initialization of an SS shall be as shown in Figure 55. This figure shows the overall flow 
between the stages of initialization in an SS. This shows no error paths and is shown simply to provide an 
overview of the process. The more detailed finite state machine representations of the individual sections 
(including error paths) are shown in the subsequent figures. Timeout values are defined in 10.1. 

The procedure can be divided into the following phases: 

a) Scan for downlink channel and establish synchronization with the BS 

b) Obtain transmit parameters (from UCD message) 

c) Perform ranging 
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Figure 55— SS Initialization overview 



d) 


Negotiate basic capabilities 


e) 


Authorize SS and perform key exchange 


f) 


Perform registration 


g) 


Establish IP connectivity 


h) 


Establish time of day 


i) 


Transfer operational parameters 


j) 


Set up connections 



Implementation of phases g), h), and i) at the SS is optional. These phases shall only be performed if the SS 
has indicated in the REG-REQ message that it is a managed SS. 

Each SS contains the following information when shipped from the manufacturer: 

a) A 48-bit universal MAC address (per IEEE Std 802-2001) assigned during the manufacturing 
process. This is used to identify the SS to the various provisioning servers during initialization. 

b) Security information as defined in Clause 7 (e.g., X.509 certificate) used to authenticate the SS to 
the security server and authenticate the responses from the security and provisioning servers. 
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6.3.9.1 Scanning and synchronization to the downlink 

On initialization or after signal loss, the SS shall acquire a downlink channel. The SS shall have nonvolatile 
storage in which the last operational parameters are stored and shall first try to reacquire this downlink 
channel. If this fails, it shall begin to continuously scan the possible channels of the downlink frequency 
band of operation until it finds a valid downlink signal. 

Once the PHY has achieved synchronization, as given by a PHY Indication, the MAC shall attempt to 
acquire the channel control parameters for the downlink and then the uplink. 

6.3.9.2 Obtain downlink parameters 

The MAC shall search for the DL-MAP MAC management messages. The SS achieves MAC 
synchronization once it has received at least one DL-MAP message. An SS MAC remains in 
synchronization as long as it continues to successfully receive the DL-MAP and DCD messages for its 
Channel. If the Lost DL-MAP Interval (Table 342) has elapsed without a valid DL-MAP message or the Tl 
interval (Table 342) has elapsed without a valid DCD message, an SS shall try to reestablish 
synchronization. The process of acquiring synchronization is illustrated in Figure 56. The process of 
maintaining synchronization is illustrated in Figure 57. 
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Figure 56— Obtaining downlink synchronization 
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Figure 57— Maintaining downlink synchronization 
6.3.9.3 Obtain uplink parameters 

After synchronization, the SS shall wait for a UCD message from the BS in order to retrieve a set of 
transmission parameters for a possible uplink channel. These messages are transmitted periodically from the 
BS for all available uplink channels and are addressed to the MAC broadcast address. 

If no uplink channel can be found after a suitable timeout period, then the SS shall continue scanning to find 
another downlink channel. The process of obtaining uplink parameters is illustrated in Figure 58. 

The SS shall determine from the channel description parameters whether it may use the uplink channel. If 
the channel is not suitable, then the SS shall continue scanning to find another downlink channel. If the 
channel is suitable, the SS shall extract the parameters for this uplink from the UCD. It then shall wait for the 
next DL-MAP message and extract the time synchronization from this message. Then, the SS shall wait for 
a bandwidth allocation map for the selected channel. It may begin transmitting uplink in accordance with the 
MAC operation and the bandwidth allocation mechanism. 

The SS shall perform initial ranging at least once, per Figure 60 and Figure 61. If initial ranging is not 
successful, the procedure is restarted from scanning to find another downlink channel. 

The SS MAC is considered to have valid uplink parameters as long as it continues to successfully receive the 
UL-MAP and UCD messages. If at least one of these messages is not received within the time intervals 
specified in Table 342, the SS shall not use the uplink. This is illustrated in Figure 59. 
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Figure 58 — Obtaining uplink parameters 
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Figure 59— Maintain uplink parameters 

6.3.9.4 Message flows during scanning and uplink parameter acquisition 

The BS shall generate UCD and DCD messages on the downlink at periodic intervals within the ranges 
defined in Table 342. The BS may generate UL-MAP and DL-MAP at intervals as specified in a particular 
PHY specification. These messages are addressed to all SSs. Refer to Table 114. 



Table 114— Message flows during scanning and uplink parameter acquisition 



BS 

clock time to send DL-MAP 
clock time to send UCD and DCD 


DL-MAP—- 

UCD and DCD- 
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> 


SS 


clock time to send DL-MAP 


DL-MAP- — 




| Example of a UCD and DCD 
| cycle prior to SS power-on 
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> 
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Table 114— Message flows during scanning and uplink parameter acquisition (continued) 



BS 






SS 


clock time to send UCD and DCD | — 


UCD and DCD 


-> 




clock time to send DL-MAP 


DL-MAP 
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r*\ r\r*\r timf» tn CATlH Til — \A A 

ClUvK. IIIIIC IU aCIlU L^i-r-lVlrVi 


DL-MAP 


> 




clock time to send DL-MAP 


DL-MAP 


> 




clock time to send UCD 


UCD 


> 


obtain parameters for this uplink 
channel to use for initialization 


clock time to send DL-MAP 


- — DL-MAP 


> 


extract slot info for uplink & 
wait for transmission 
opportunity to perform ranging 


clock time to send DL-MAP 


DL-MAP 


> 




clock time to send UL-MAP 


UL-MAP 


> 


start ranging process 



6.3.9.5 Initial ranging and automatic adjustments 

Ranging is the process of acquiring the correct timing offset and power adjustments such that the SS's 
transmissions are aligned to a symbol that marks the beginning of a minislot boundary in SC and Sea PHY, 
or aligned with the BS receive frame for OFDM and OFDMA PHY, and received within the appropriate 
reception thresholds. The timing delays through the PHY shall be relatively constant. Any variation in the 
PHY delays shall be accounted for in the guard time of the uplink PHY overhead. 

6.3.9.5.1 Contention based Initial ranging and automatic adjustments 

First, an SS shall synchronize to the downlink and learn the uplink channel characteristics through the UCD 
MAC management message. At this point, the SS shall scan the UL-MAP message to find an Initial Ranging 
Interval. The BS shall allocate an Initial Ranging Interval consisting of one or more transmission 
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opportunities. For SC, SCa, and OFDM PHY, the size of each transmission opportunity shall be as specified 
by the UCD TLV, Ranging request opportunity size. 

For SC, SCa, and OFDM PHY, the SS shall put together a RNG-REQ message to be sent in an Initial 
Ranging Interval. The CID field shall be set to the non initialized SS value (zero). For the OFDMA PHY, the 
initial ranging process shall begin by sending initial-ranging CDMA codes on the UL allocation dedicated 
for that purpose (for more details see 6.3.10.3), instead of RNG-REQ messages sent on contention slots. 

Ranging adjusts each SS's timing offset such that it appears to be co-located with the BS. The SS shall set its 
initial timing offset to the amount of internal fixed delay equivalent to colocating the SS next to the BS. This 
amount includes delays introduced through a particular implementation and shall include the downlink PHY 
interleaving latency, if any. 

When the Initial Ranging transmission opportunity occurs, the SS shall send the RNG-REQ message (or a 
CDMA code in case of the OFDMA PHY). Thus, the SS sends the message as if it were colocated with the 
BS. 

The SS shall calculate the maximum transmit signal strength for initial ranging, Pjxjr MAX' from Equation 
(10). 

^TXJR.MAX = EIRxP IR>max + BS.EIRP - RSS (10) 

where the EIRxP IR max and BS_EIRP are obtained from the DCD, and RSS is the measured RSSI, by the 
SS, as described in the respective PHY. 

In the case that the receive and transmit gain of the SS antennae are substantially different, the SS shall use 
Equation (11). 

*rx_IR_MAX = EIR x P IR>max + BS_EIRP - RSS +(G Rx _ ss -Gr x _ ss ). (11) 
where 

^Rx_SS * s me ^ receive antenna gain, 
Gr x _ ss is the SS transmit antenna gain. 

In the case that the EIR x P\ RfmQX and/or BS_EIRP are/is not known, the SS shall start from the minimum 
transmit power level defined by the BS 

NOTE — The EIRxP IR max is the maximum equivalent isotropic received power, which is computed for a simple single- 
antenna receiver as RSS IR max - GANT_BS_Rx, where the RSSjr max is the received signal strength at antenna output 
and GANT_BS_Rx is the receive antenna gain. The BS_EIRP is' the equivalent isotropic radiated power of the base 
station, which is computed for a simple single-antenna transmitter as P Tx + GANT_BS_Tx, where P Tx is the transmit 
power and GANT_BS_Tx is the transmit antenna gain. 

For SC, SCa, and OFDM PHY, the SS shall send the RNG-REQ at a power level below ^txjr^max* 
measured at the antenna connector. If the SS does not receive a response, the SS shall resend the RNG-REQ 
at the next appropriate Initial Ranging transmission opportunity at one step higher power level. If the SS 
receives a response containing the frame number in which the RNG-REQ was transmitted, it shall consider 
the transmission attempt unsuccessful but implement the corrections specified in the RNG-RSP and issue 
another RNG-REQ message after the appropriate backoff delay. If the SS receives a response containing its 
MAC Address, it shall consider the RNG_RSP reception successful. 

When a WirelessMAN-SCa or WirelessMAN-OFDM BS detects a transmission in the ranging slot that it is 
unable to decode, it may respond by transmitting a RNG-RSP that includes transmission parameters, but 
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identifies the frame number and frame opportunity when the transmission was received instead of the MAC 
Address of the transmitting SS. 

For OFDMA, the SS shall send a CDMA code at a power level below P T X_IR_MAX> measured at the antenna 
connector. If the SS does not receive a response, the SS shall send a new CDMA code at the next appropriate 
Initial Ranging transmission opportunity at one step higher power level. If the SS receives a RNG-RSP 
message containing the parameters of the code it has transmitted and status continue, it shall consider the 
transmission attempt unsuccessful but implement the corrections specified in the RNG-RSP and issue 
another CDMA code after the appropriate backoff delay. If the SS receives an UL-MAP containing a CDMA 
allocation IE with the parameters of the code it has transmitted, it shall consider the RNG_RSP reception 
successful, and proceed to send a unicast RNG-REQ on the allocated BW. More details on this procedure 
can be found in 6.3.10.3. 

Once the BS has successfully received the RNG-REQ message, it shall return a RNG-RSP message using 
the initial ranging CID. Within the RNG-RSP message shall be the Basic and Primary Management CIDs 
assigned to this SS. The message shall also contain information on RF power level adjustment and offset 
frequency adjustment as well as any timing offset corrections. At this point the BS shall start using invited 
Initial Ranging Intervals addressed to the SS's Basic CID to complete the ranging process, unless the status 
of the RNG-RSP message is success, in which case the initial ranging procedure shall end. 

If the status of the RNG-RSP message is continue, the SS shall wait for an individual Initial Ranging interval 
assigned to its Basic CID. Using this interval, the SS shall transmit another RNG-REQ message using the 
Basic CID along with any power level and timing offset corrections. 

The BS shall return another RNG-RSP message to the SS with any additional fine tuning required. The 
ranging request/response steps shall be repeated until the response contains a Ranging Successful 
notification or the BS aborts ranging. Once successfully ranged (RNG-REQ is within tolerance of the BS), 
the SS shall join normal data traffic in the uplink. In particular, state machines and the applicability of retry 
counts and timer values for the ranging process are defined in Table 342. 

NOTE— The burst profile to use for any uplink transmission is defined by the Uplink Interval Usage Code (UIUC). Each 
UIUC is mapped to a burst profile in the UCD message. 

For SC, SCa, and OFDM PHY, the message sequence chart (Table 115) and flow charts (Figure 60, 
Figure 61, Figure 62, and Figure 63) on the following pages define the ranging and adjustment process that 
shall be followed by compliant SSs and BSs. For OFDMA PHY, these details can be found in 6.3.10.3. 

Table 115— Ranging and automatic adjustments procedure 



BS 



SS 



[time to send the Initial Ranging 
opportunity] 

send map containing Initial UL-MAP > 



Ranging IE with a broadcast 
Connection ID 



-RNG-REQ transmit ranging packet in con- 

tention mode with Connection 
ID parameter = 0 



a [if detect un-decodable ranging 
packet] 
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Table 115 — Ranging and automatic adjustments procedure (continued) 



BS 




SS 


a send ranging response, includ- 
ing Frame Number, Frame 
Opportunity, CID=0 


- RNG-RSP 3 - > 


a [recognize frame number/ 
opportunity when packet was 
sent] 

Adjust parameters, prepare to 
transmit another RNG-REQ 
at next opportunity 


[else receive decodable ranging 
packet] 






allocate Basic and Primary 
Management Connection ID 






send ranging response 


RNG-RSP > 




add Basic Connection ID to 
poll list 




[recognize own MAC Address] 
store Basic Connection ID 
and adjust other parameters 


[time to send the next map] 






send map with Initial Ranging 
IE to SS using Basic CID 


UL-MAP > 


[recognize own Basic Connec- 
tion ID in map] 




< RNG-REO 


rpnlv tr\ Initial RnnoSna 
iC|Jijr ivj initial ivallglllg 

opportunity poll 


send ranging response 


RNG-RSP > 


adjust local parameters 


send periodic transmit opportu- 
nity to broadcast address 


UL-MAP > 





l WirelessMAN-SCa and WirelessMAN-OFDM PHY only. 



NOTES 

1 — The BS shall allow the SS sufficient time to have processed the previous RNG-RSP (i.e., to modify the transmitter 
parameters) before sending the SS a specific ranging opportunity. This is defined as SS Ranging Response Processing 
Time in Table 342. 

2 — For multichannel support, the SS shall attempt initial ranging on every suitable uplink channel before moving to the 
next available downlink channel. 

On receiving a RNG-RSP instruction to move to a new downlink frequency and/or uplink channel ID, the 
SS shall consider any previously assigned Basic, Primary Management, and Secondary Management CIDs 
to be deassigned, and shall obtain new Basic, Primary Management, and Secondary Management CIDs via 
initial ranging and registration. 

It is possible that the RNG-RSP may be lost after transmission by the BS. The SS shall recover by timing out 
and reissuing its Initial RNG-REQ. Since the SS is uniquely identified by the source MAC address in the 
Ranging Request, the BS may immediately reuse the Basic, Primary Management, and Secondary 
Management CIDs previously assigned. If the BS assigns new Basic, Primary Management, and Secondary 
Management CIDs, it shall make some provision for aging out the old CIDs that went unused. 
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6.3.9.6 Ranging parameter adjustment 

Adjustment of local parameters (e.g., transmit power) in an SS as a result of the receipt (or non receipt) of a 
RNG-RSP is considered to be implementation-dependent with the following restrictions: 

a) All parameters shall be within the approved range at all times. 

b) Power adjustment shall start from the initial value selected with the algorithm described in 6.3.9.5 
unless a valid power setting is available from nonvolatile storage, in which case this value may be 
used as the starting point. 

c) Power adjustment shall be capable of being reduced or increased by the specified amount in 
response to RNG-RSP messages. 

d) If, during initialization, power is increased to the maximum value (without a response from the BS) 
it shall wrap back to the minimum 

On receiving a RNG-RSP, the SS shall not transmit until the RF signal has been adjusted in accordance with 
the RNG-RSP and has stabilized. 



Timeout 
T2 



Mark DL 
channel unusable 



Start T1 9 



Scan for 
Downlink 
Channel 



Wait for Initial ^ 

Ranging 
opportunity 



UL-MAPwith 

Ranging 
opportunity 



Send 
RNG-REQ 



Start T3 



f Wait for 
RNG-RSP 



Figure 60— Initial Ranging— SS (part 1) 
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Figure 61— Initial Ranging— SS (part 2) 
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Figure 62— Initial Ranging— BS 
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Figure 63— Initial Ranging, Polled Phase-BS 
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For systems operating below 11 GHz, the BS may in addition respond to undecodable messages in an Initial 
Ranging slot as shown in Figure 64. 
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Figure 64— Initial ranging— BS response to undecodable message 



6.3.9.7 Negotiate basic capabilities 

Immediately after completion of ranging, the SS informs the BS of its basic capabilities by transmitting an 
SBC-REQ message with its capabilities set to "on" (see Figure 65). The BS responds with an SBC-RSP 
message with the intersection of the SS's and the BS's capabilities set to "on" (see Figure 66 and Figure 67, 
respectively). 
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Figure 65 — Negotiate Basic Capabilities— SS 
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Figure 66— Wait for SBC-RSP— SS 
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Figure 67— Negotiate Basic Capabilities— BS 



Copyright ©2004 IEEE. All rights reserved. 



183 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



6.3.9.8 SS authorization and key exchange 

The BS and SS shall perform authorization and key exchange as described in 7.2. 

6.3.9.9 Registration 

Registration is the process by which the SS is allowed entry into the network and a managed SS receives its 
Secondary Management CID and thus becomes manageable. To register with a BS, the SS shall send a REG- 
REQ message to the BS. The BS shall respond with a REG-RSP message. For an SS that has indicated being 
a managed SS in the REG-REQ message, the REG-RSP message shall include the Secondary Management 
CID. 

Figure 68 shows the procedure that shall be followed by the SS. 




Start T6 




Figure 68— Registration — SS 
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Once the SS has sent a REG-REQ to the BS, it shall wait for a REG-RSP to authorize it to forward traffic to 
the network. Figure 69 shows the waiting procedure that shall be followed by the SS. 
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Figure 69— Wait for REG-RSP— SS 
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The BS shall perform the operations shown in Figure 70, 
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Figure 70— Registration— BS 



For managed SS, upon sending a REG-RSP, the BS shall wait for a TFTP-CPLT. If timer T13 (defined in 
Table 342) expires, the BS shall both deassign the management CIDs from that SS and make some provision 
for aging out those CIDs (see Figure 71 and Figure 72).. 

6.3.9.9.1 IP version negotiation 

The SS may include the IP Version (11.7.4) parameter in the REG-REQ to indicate which versions of IP it 
supports on the Secondary Management Connection. When present in the REG-REQ, the BS shall include 
the IP Version parameter (11.7.4) in the REG-RSP to command the SS to use the indicated version of IP on 
the Secondary Management Connection. The BS shall command the use of exactly one of the IP versions 
supported by the SS. 
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The omission of the IP Version parameter in the REG-REQ shall be interpreted as IPv4 support only. 
Consequently, omission of the IP Version parameter in the REG-RSP shall be interpreted as a command to 
use IPv4 on the Secondary Management Connection. 

6.3.9.10 Establish IP connectivity 

At this point, the SS shall invoke DHCP mechanisms (IETF RFC 2131) in order to obtain an IP address and 
any other parameters needed to establish IP connectivity. If the SS has a configuration file, the DHCP 
response shall contain the name of a file that contains further configuration parameters. Establishment of IP 
connectivity shall be performed on the SS's Secondary Management Connection (see Table 116). 



Table 116— Establishing IP connectivity 



SS/Node 




DHCP 


Send DHCP request to 
broadcast address 


DHCP discover- > 


Check SS MAC address and 
respond 


< 


DHCP offer 




Choose server 


DHCP request > 


Process request 


< 


DHCP response 




Set up IP parameters from 
DHCP response 






6.3.9.11 Establish time of day 



The SS and BS need to have the current date and time. This is required for time-stamping logged events for 
retrieval by the management system. This need not be authenticated and need be accurate only to the nearest 
second. 



The protocol by which the time of day shall be retrieved is defined in IETF RFC 868. Refer to Table 1 17. 
The request and response shall be transferred using UDP. The time retrieved from the server [universal 
coordinated time (UTC)] shall be combined with the time offset received from the DHCP response to create 
the current local time. Establishment of time of day shall be performed on the SS's Secondary Management 
Connection. 
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Table 117— Establishing time of day 



SS 




Time Server 


send request to time server 


time of day request > 

< time of day response 


process request 


set up / correct time of day 
from response 







Successfully acquiring the Time of Day is not mandatory for a successful registration, but is necessary for 
ongoing operation. The specific timeout for Time of Day Requests is implementation dependent. However, 
the SS shall not exceed more than three Time of Day requests in any five-minute period. 

6.3.9.12 Transfer operational parameters 

After DHCP is successful, the SS shall download the SS Configuration File (9.2) using TFTP on the SS's 
Secondary Management Connection, as shown in Table 118 if specified in the DHCP response. The TFTP 
Configuration File server is specified by the "siaddr" field of the DHCP response. The SS shall use an 
adaptive timeout for TFTP based on binary exponential backoff (IETF RFC 1123, IETF RFC 2349). 



Table 118 — Transfer of Operational Parameters 



SS 




BS TFTP Server 


Initiate TFTP Get protocol 








.... TFTP Config File 




Inform BS of completion 








TFT-CPLT 


> 

Acknowledge 

completion j 




TFT-RSP 


. Establish 
provisioned 
connections 



The parameter fields required in the DHCP response and the format and content of the configuration file 
shall be as defined in 9.2. Note that these fields are the minimum required for interoperability. 
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When the configuration file download has completed successfully, the SS shall notify the BS by transmitting 
a TFTP-CPLT message on the SS's primary management connection. Transmissions shall continue 
periodically until a TFTP-RSP message is received with "OK" response from the BS (see Figure 71 and 
Figure 72) or the SS terminates retransmission due to retry exhaustion. 



Walt For >v 
TFTP-CPLT J 



i Timeout T13 



Deassign 
management 
SS CIDs 



> TFTP-CPLT 



TFTP-RSP 



Establish 
provisioned 
connections 



Figure 71— Wait for TFTP-CPLT— BS 
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6.3.9.13 Establish provisioned connections 

After the transfer of operational parameters (for managed SS) or after registration (for unmanaged SS), the 
BS shall send DSA-REQ messages to the SS to set up connections for preprovisioned service flows belong- 
ing to the SS. The SS responds with DSA-RSP messages. This is described further in 6.3.14.7.1. 

6.3.9.14 Network Entry and synchronization in Mesh mode 

Node initialization and network entry procedures in Mesh mode are in some aspects different from those in 
PMP mode. A new node entering the Mesh network obeys the following procedures. The whole entry pro- 
cess to the stage when the node can start scheduled transmissions can be divided into the following phases: 

a) Scan for active network and establish coarse synchronization with the network 

b) Obtain network parameters (from MSH-NCFG messages) 

c) Open Sponsor Channel 

d) Node authorization 

e) Perform registration 

f) Establish IP connectivity 

g) Establish time of day 

h) Transfer operational parameters 

The entry process is depicted in Figure 56, Figure 74, and Figure 75. 

Each node contains the following information when shipped from the manufacturer: 

— A 48-bit universal MAC address (per IEEE Std 802) assigned during the manufacturing process. 
This is used to identify the node to the various provisioning servers during initialization and 
whenever performing authentication with a neighbor node. 

6.3.9.14.1 Scanning and coarse synchronization to the network 

On initialization or after signal loss, the node shall search for MSH-NCFG messages to acquire coarse 
synchronization with the network. Upon receiving a MSH-NCFG message the node acquires the network 
time from the Timestamp field of the message. The node may have nonvolatile storage in which all the last 
operational parameters are stored and shall first try to re-acquire coarse synchronization with the network. If 
this fails, it shall begin to continuously scan the possible channels of the frequency band of operation until a 
valid network is found. 

Once the PHY has achieved synchronization, the MAC shall attempt to acquire network parameters. At the 
same time the node shall build a physical neighbor list. 

6.3.9.14.2 Obtaining network parameters 

A node shall remain in synchronization as* long as it receives MSH-NCFG messages. A node shall 
accumulate MSH-NCFG messages at least until it receives a MSH-NCFG message from the same node 
twice and until it has received a MSH-NCFG: Network Descriptor with an operator ID matching (one of) its 
own if it has any. In parallel, the new node shall build a physical neighbor list (see 6.3.7.5.5.1) from the 
acquired information. 

From the established physical neighbor list, the new node shall select a potential Sponsoring Node out of all 
nodes having the Logical Network ID of the node for which it found a suitable Operator ID. The new node 
shall then synchronize its time to the potential sponsor assuming 0 propagation delay after which it shall 
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send a MSH-NENT:NetEntryRequest including the Node ID of the potential sponsor. To determine a 
suitable transmission time, the node shall adhere to 6.3.7.5.5.7. 

Until the node has obtained an unique Node ID (see 6.3.9.14.5), it shall use temporary Node ID (0x0000) as 
Transmitter's Node ID in all transmissions. 

Once the Candidate Node has selected a Sponsoring Node, it shall use the Sponsoring Node to negotiate 
basic capabilities and to perform authorization. For that purpose the Candidate Node shall first request the 
Sponsoring Node to open Sponsor Channel for more effective message exchange. 

6.3.9.14.3 Open Sponsor Channel 

Once the new node has selected one of its neighbors as the candidate Sponsoring Node it becomes a 
Candidate Node. To get further in the initialization procedure, the Candidate Node shall request the 
candidate Sponsoring Node to establish a temporary schedule that could be used for further message 
delivery during the Candidate Node initialization. The temporary schedule requested is termed Sponsor 
Channel. 

The process is initiated by the Candidate Node, which transmits a MSH-NENT:NetEntry Request message (a 
MSH-NENT message with Type set to 0x2) to the Sponsoring Node. 

Upon reception of the MS H-NENT:NetEn try Request message with the Sponsor Node ID equal to Node ID 
of its own, the candidate Sponsoring Node shall assess the request and either opens the Sponsor Channel or 
rejects the request. The response is given in a MSH-NCFG message with an Embedded Data as defined in 
6.3.2.3.35.3. If the candidate Sponsoring Node does not advertise the Candidate Node's MAC address in the 
sponsor's next MSH-NCFG transmission, then the procedure is repeated MSH_SPONSOR_ATTEMPTS 
times using a random backoff between attempts. If these attempts all fail, then a different Candidate 
Sponsoring Node is selected and the procedure repeated (including re-initializing coarse network synchroni- 
zation). If the selected candidate Sponsoring Node does advertise the Candidate Node's MAC address, it 
shall continue to advertise this MAC address in all its MSH-NCFG messages until the sponsorship is 
terminated. 

Once the Candidate Node has received a positive response (a NetEntryOpen message) in from the candidate 
Sponsoring Node in the MSH-NCFG message, it shall acknowledge the response by transmitting a MSH- 
NENT:NetEntryAck message (a MSH-NENT message with Type set to 0x1) to the Sponsoring Node at the 
first following network entry transmission opportunity (see 8.3.5.3). Before that the Candidate Node shall 
perform fine time synchronization. It makes a correction to its transmission timing by the Estimated 
propagation delay indicated in the embedded MSH-NCFG:NetEntryOpen message. 

If the Sponsoring Node accepts the request and opens a Sponsor Channel, the channel is ready for use 
immediately after the transmission of the acknowledgment message. At the same time, the candidate 
Sponsoring Node becomes the Sponsoring Node. 

If the candidate Sponsoring Node embeds a MSH-NCFG:NetEntryReject, the new node shall perform the 
following action based on the rejection code: 

0x0: Operator Authentication Value Invalid 

The Candidate Node shall select a new candidate Sponsoring Node with a different operator 
ID. 

Ox 1 : Excess Propagation delay 

The Candidate Node shall repeat its MSH-NENT:NetEntryRequest in the following network 
entry transmission opportunity to the same candidate Sponsoring Node. 

0x2: Select new sponsor 

The Candidate Node shall select a new candidate Sponsoring Node. 
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If the candidate Sponsoring Node embedded neither MSH-NCFG:NetEntryOpen nor MSH- 
NCFG:NetEntryReject, the Candidate Node shall wait (with timeout time T23), for the next MSH-NCFG 
with NetEntryOpen from the candidate Sponsoring Node and resend the MS H-NENT:NetEntry Request on 
timeout. 

The Candidate Node and the Sponsoring Node use the schedule indicated in the NetEntryOpen message to 
perform message exchanges described in 6.3.9.14.4 through 6.3.9.14.9. After this is completed, the 
Candidate Node shall terminate the entry process by sending a MSH-NENT:NetEntryClose message to the 
Sponsoring Node in the network entry transmission immediately following a MSH-NCFG transmission 
from the Sponsoring Node, which shall Ack termination with MSH-NCFG :NetEntryAck. 
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Figure 73— Mesh network synchronization and entry— New node— I 
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Figure 75 — Mesh network synchronization and entry— Sponsor node 
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Table 119 displays the message transfer sequence during a successful network entry without repetitions or 
timeouts. 



Table 119— Successful network entry message exchange 



Sponsor node 








New node 


Nodes in network routinely 
advertise network with Network 
L/escnptor ^see o.d. i 

Node can decide to respond 




MSH-NCFG: 
Network Descriptor 








MSH-NENT: 
NetEntryRequest 




New node at startup searches for 
MSH-NCFG messages with 
Network Descriptor (see also 
Figure 73). 


negatively with NetEntryReject 
or can respond positively with 
NetEntryOpen reporting new 
node's MAC address and 
schedule allocation for higher- 
layer authentication and 
configuration exchange. 




MSH-NCFG: 
NetEntryOpen 










MSH-NENT: 
NetEntryAck 




New node sends ACK to confirm 
schedule. 


Security sublayer and basic capability exchange operations 






MSH-NENT: 
NetEntryClose 




After authentication and«config- 
uration have been completed, 
node closes the entry procedure. 

Node is now regular node in the 
network. 


Sponsor ACK's closure of 
sponsorship. 

In following MSH-NCFG 
packets, node sends all-zero 
NetEntry MAC address 
(indicating ready to sponsor new 
node) or sets NetEntry MAC 
address flag to 0. 




MSH-NENT: 
NetEntryAck 











6.3.9.14.4 Negotiate basic capabilities 

In Mesh mode, the basic capabilities shall be negotiated as described in 6.3.9.7 after a logical link has been 
established between two nodes. The node that requested the logical link (see 6.3.1.2) shall act as the SS and 
initiate the SBC-REQ. 

6.3.9.14.5 Node authorization 



The new node shall perform authorization as described in 7.2. The new node shall act as the SS. The sponsor 
node upon reception of the Auth Info and Auth Request shall tunnel the messages as described in 6.3.16 to 
the Authorization Node. The Authorization Node, acting as the BS, shall verify the SS Certificate of the new 
node and determine whether the new node is authorized to join the Network. Upon receiving tunneled PKM- 
RSP MAC messages from the Authorization Node the Sponsor shall forward the messages to the new node. 

6.3.9.14.6 Node registration 

Registration is the process where a node is assigned its Node ID. The sponsoring node upon reception of the 
REG-REQ shall tunnel the message as described in 6.3.16 to the Registration Node. Upon receiving 
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tunneled REG-RSP MAC messages from the Registration Node the Sponsor shall forward the messages to 
the new node. The new node shall follow the procedure in Figure 76 and Figure 77. The Registration Node 
shall follow the procedure in Figure 70. 



Register with 
Network 




Figure 76— Registration— Candidate node 
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J 



Establish IP 
connectivity 



Figure 77 — Wait for registration response — Candidate node 
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Figure 78— Registration— Registration node 



6.3.9.14.7 Establish IP connectivity 

The Node shall acquire an IP address using DHCP. The procedure is shown in Table 116 and takes place 
over the Sponsor Channel. 

6.3.9.14.8 Establish time of day 

The Nodes in a Mesh network shall retrieve the time of day using the protocol defined in IETF RFC 868. 
The messages shall be carried over UDP in the Sponsor Channel. 

6.3.9.14.9 Transfer operational parameters 

After successfully acquiring an IP address via DHCP, the Node shall download a parameter file using TFTP. 
The procedure is described in 6.3.9.12. The Node shall use the Sponsor Channel for this purpose instead of 
the Secondary Management connection. 
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6.3.9.14.10 Setup provisioned traffic parameters 

Using Mesh, QoS is provisioned on a packet-by-packet basis using the Mesh CID. Hence, the connection- 
based QoS provisioning using the DSx messages defined in 6.3.14 are not used. A Mesh node obtains its 
AuthorizedQoSParamSet during the transfer of operational parameters. 

6.3.9.14.11 Establishing links to neighbors 

After entering the network, a node can establish links with nodes other than its sponsor by following the 
secure process as defined in Table 120. This process uses the MSH-NCFG:Neighbor Link Establishment IE. 

a) Node A sends a challenge (action code = 0x0) containing: 

HMAC{ Operator Shared Secret, frame number, Node ID of node A, Node ID of node B } 
where the Operator Shared Secret is a private key obtained from the provider (which is also 
used to enter the network) and the frame number is the last known frame number in which 
Node B sent a MSH-NCFG message. 

b) Node B, upon reception, computes the same value (it may also attempt some earlier frame numbers 
where it sent MSH-NCFG messages, in case node A missed the last of its MSH-NCFGs) in item a) 
and compares. If the values do not match, a rejection (action code = 0x3) is returned. If a match is 
achieved, Node B sends, implicitly accepting the link, a challenge response (action code=0xl) 
containing: 

HMAC{Operator Shared Secret, frame number, Node ID of node B, Node ID of node A} 
where the frame number is the frame number in which Node A sent the MSH-NCFG message 
with challenge. It also randomly selects and includes an unused link ID, which shall from this 
point forward indicate the link from node B to node A. 

c) Node A, upon reception, computes the same value in item b) and compares. If the values do not 
match, a rejection (action code = 0x3) is returned. If a match is achieved, Node A sends an Accept. 
It also randomly selects and includes an unused link ID, which shall from this point forward indicate 
the link from node A to node B. 



Table 120— Establishing link connectivity 



Node A 



NodeB 



send challenge 
(action code=0x0) 



•Challenge- 



> 



if HMAC{} match, send 
challenge response 
(action code=0xl) 



-Challenge response- 



if HMAC{ } match, send 
Accept 
(action code=0x2) 



— Accept- 



> 
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6.3.10 Ranging 

Ranging is a collection of processes by which the SS and BS maintain the quality of the RF communication 
link between them. Distinct processes are used for managing uplink and downlink. Also some PHY modes 
support ranging mechanisms unique to their capabilities. 

6.3.10.1 Downlink burst profile management 

The downlink burst profile is determined by the BS according to the quality of the signal that is received by 
each SS. To reduce the volume of uplink traffic, the SS monitors the CINR and compares the average value 
against the allowed range of operation. This region is bounded by threshold levels. If the received CINR 
goes outside of the allowed operating region, the SS requests a change to a new burst profile using one of 
two methods. If the SS has been granted uplink bandwidth (a data grant allocation to the SS's Basic CID), 
the SS shall send a DBPC-REQ message in that allocation. The BS responds with a DBPC-RSP message. If 
a grant is not available and the SS requires a more robust burst profile on the downlink, the SS shall send a 
RNG-REQ message in an Initial Ranging interval. With either method, the message is sent using the Basic 
CID of the SS. The coordination of message transmit and receipt relative to actual change of modulation is 
different depending upon whether an SS is transitioning to a more or less robust burst profile. Figure 79 
shows the case where an SS is transitioning to a more robust type. Figure 80 shows transition to a less robust 
burst profile. 

The SS applies an algorithm to determine its optimal burst profile in accordance with the threshold 
parameters established in the DCD message in accordance with Figure 81. 
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Figure 79— Transition to a more robust burst profile 
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Figure 80— Transition to a less robust burst profile 



No 



CD 

DC 
2 

O 



0 —I 




Burst Profile #Z Minimum Entry Threshold 
Burst Profile #Z Mandatory Exit Threshold 



* — Burst Profile #Y Minimum Entry Threshold 

* — Burst Profile #Y Mandatory Exit Threshold 

— — Burst Profile #X Minimum Entry Threshold 

— Burst Profile #X Mandatory Exit Threshold 
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6.3.10.2 Uplink periodic ranging 

Uplink ranging consists of two procedures — initial ranging and periodic ranging. Initial ranging (see 6.3.9.5) 
allows an SS joining the network to acquire correct transmission parameters, such as time offset and Tx 
power level, so that the SS can communicate with the BS. Following initial ranging, periodic ranging allows 
the SS to adjust transmission parameters so that the SS can maintain uplink communications with the BS. 

The following summarizes the general algorithm for periodic ranging available to all PHY layers. Diagrams 
of the SS and BS processes are provided in Figure 82, Figure 83, and Figure 84. CDMA-based ranging for 
OFDMA systems is described in 6.3.10.3. 

1) For each SS, the BS shall maintain a T27 timer. At each expiration of the timer, the BS shall 
grant bandwidth to the SS for an uplink transmission. The timer is restarted each time a unicast 
grant is made to the SS. As a result, as long as the SS remains active, the BS does not 
specifically grant bandwidth to the SS for a ranging opportunity. 

2) Each SS shall maintain a T4 timer. The expiration of this timer indicates to the SS that it has 
not been given the opportunity to transmit to the BS for an extended period of time. Operating 
on the assumption that its uplink transmission parameters are no longer usable, the SS initiates 
a restart of its MAC operations 

3) For each unicast uplink burst grant, the BS determines whether or not a transmitted signal is 
present. If no signal is detected in a specified number of successive grants, the BS shall 
terminate link management for the associated SS. 

4) For each unicast uplink burst grant in which a signal is detected, the BS makes a determination 
as to the quality of the signal. If the signal is within acceptable limits and the data carried in the 
burst includes the RNG-REQ message, the RNG-RSP message shall be issued with a status of 
success. If the signal is not within acceptable limits, the RNG-RSP message shall be issued that 
includes the appropriate correction data and a status of continue. If a sufficient number of cor- 
rection messages are issued without the SS signal quality becoming acceptable, the BS shall 
send the RNG-RSP message with a status of abort, and terminate link management of the SS. 

5) The SS shall process each RNG-RSP message it receives, implementing any PHY corrections 
that are specified (when the status is continue) or initiating a restart of MAC activities (when 
the status is abort). 

6) The SS shall respond to each uplink bandwidth grant addressed to it. When the status of the last 
RNG-RSP message received is continue, the RNG-REQ message shall be included in the 
transmitted burst. When the status of the last RNG-RSP message received is success, the SS 
shall use the grant to service its pending uplink data queues. If no data is pending, the SS shall 
respond to the grant by transmitting a block of padded data. 



202 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



Yes 



1 


f 


Clear 




Invited 




count 






No 



1 


f 




Increment 




Invited 




counter 



No 




RNG-REQ 



\. in data S 




|Yes 




Reset 
retry count 




r 




RNG-RSP \ 
(success) / 


y 


f 




Start T27 with 
idle interval 




r 



RNG-RSP ' 
(continue, 
corrections). 




Increment 
Correction 
count 




Yes 



Remove SS 
from BS 
management 



RNG-RSP 
(abort) 



Start T27 with 
active interval 



Done 




Figure 82— Periodic Ranging receiver processing— BS 
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Figure 83— Periodic Ranging opportunity allocation 
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Figure 84— Periodic Ranging— SS 



6.3.10.3 OFDM A-based ranging 

The WirelessMAN-OFDMA PHY specifies a Ranging Subchannel and a set of special pseudonoise Ranging 
Codes. Subsets of codes shall be allocated in the UCD Channel Encoding for Initial Ranging, Periodic 
Ranging and Bandwidth Requests, such that the BS can determine the purpose of the received code by the 
subset to which the code belongs. An example of Ranging Channel in OFDMA frame structure is specified 
in Figure 218. 
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SSs that wish to perform one of the aforementioned operations shall select, with equal probability, one of the 
codes of the appropriate subset, modulate it onto the Ranging Subchannel, and subsequently transmit in 
ranging slot selected with equal probability from the available ranging slots on the UL subframe. Details on 
the modulation and Ranging Codes are specified in 8.4.7. 

6.3.10.3.1 Contention based initial ranging and automatic adjustments 

A SS that wishes to perform initial ranging shall take the following steps: 

— The SS, after acquiring downlink synchronization and uplink transmission parameters, shall choose 
randomly a Ranging Slot (with the use of a binary truncated exponent algorithm to avoid possible 
re-collisions) at the time to perform the ranging, then it chooses randomly a Ranging Code (from the 
Initial Ranging domain) and sends it to the BS (as a CDMA code). 

— The BS cannot tell which SS sent the CDMA ranging request; therefore, upon successfully receiving 
a CDMA Ranging Code, the BS broadcasts a Ranging Response message that advertises the 
received Ranging Code as well as the ranging slot (OFDMA symbol number, subchannel, etc.) 
where the CDMA Ranging code has been identified. This information is used by the SS that sent the 
CDMA ranging code to identify the Ranging Response message that corresponds to its ranging 
request. The Ranging Response message contains all the needed adjustment (e.g., time, power, and 
possibly frequency corrections) and a status notification. 

— When the BS receives an initial-ranging CDMA code that results in sending an RNG-RSP message 
with success status, the BS shall provide BW allocation for the SS using the CDMA_Allocation_IE 
to send an RNG-REQ message. 

— Upon receiving a Ranging Response message with continue status, the SS shall continue the ranging 
process as done on the first entry with ranging codes randomly chosen from the Periodic Ranging 
domain. 

— Using the OFDMA ranging mechanism, the periodic ranging timer is controlled by the SS, not the 
BS. 

Adjustment of local parameters (e.g., transmit power) in an SS as a result of the receipt (or nonreceipt) of a 
RNG-RSP is considered to be implementation-dependent with the following restrictions: 

a) All parameters shall be within the approved range at all times. 

b) Power adjustment shall start from the initial value selected with the algorithm described in 6.3.9.5 
unless a valid power setting is available from nonvolatile storage, in which case this value may be 
used as the starting point. 

c) Power adjustment shall be capable of being reduced or increased by the specified amount in 
response to RNG-RSP messages. 

d) If, during initialization, power is increased to the maximum value (without a response from the BS) 
it shall wrap back to the minimum. 

On receiving an RNG-RSP, the SS shall not transmit until the RF signal has been adjusted in accordance 
with the RNG-RSP and has stabilized. 

The message sequence chart (Table 121) and flow charts (Figure 85, Figure 86, and Figure 87) on the 
following pages define the ranging and adjustment process that shall be followed by compliant SSs and BSs. 
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Table 121— CDMA initial Ranging and automatic adjustments procedure 



BS 




SS 


[time to send the CDMA Initial 
Ranging opportunity] 






send map containing CDMA 
Initial Ranging IE with a 
broadcast Connection ID 


UL-MAP > 






< Ranging Code 


Transmit randomly selected 
Initial Ranging code in a ran- 
domly selected Ranging Slot 
from available Ranging Region 


[Receive Ranging Code] 






Send RNG-RSP with 
Time & Power Corrections 
and original Ranging Code and 
Ranging Slot 


RNG-RSP > 




Status = Continue 




Receive RNG-RSP message 
with Ranging Code and 
Ranging Slot matching sent 
values Adjust Time & Power 
parameters 


[time to send the CDMA Initial 
Ranging opportunity] 






send map containing CDMA 
Initial Ranging IE with a 
broadcast Connection ID 


— -UL-MAP > 






< Ranging Code 


Transmit randomly selected 
Periodic Ranging code in a 
randomly selected Ranging 
Slot from available Ranging 
Region 


[Receive Ranging Code] 






Send RNG-RSP with 
Time & Power Corrections 
and original Ranging Code and 
Ranging Slot 


RNG-RSP > 




Status = Success 




Receive RNG-RSP message 
with Ranging Code and Rang- 
ing Slot matching sent values 
Adjust Time and Power 
parameters 
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Table 121— CDMA initial Ranging and automatic adjustments procedure (continued) 



BS 




SS 


[time to send the next map] 






send map containing 
anonymous BW allocation 
with original Ranging Code 
and Ranging Slot 


UL-MAP > 






< RNG-REQ 


Transmit RNG-REQ and 
continue with regular Initial 
network entry 



Wait for Initial 

Ranging 
opportunity 



Timeout 
T2 



UL-MAP with 

Ranging 
opportunity 



Mark DL 
channel unusable 



Send Ranging 

Code in 
Ranging Slot 



Start T1 9 



Start T3 



Scan for 
Downlink 
Channel 



▼ 

f Wait for ^ 
anonimous 

J I RNG-RSP I 



Figure 85 — CDMA Initial Ranging— SS (part 1) 
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Wait for 
anonymous 
RNG-RSP 



NOTE— Timeout T3 may occur 
because the CDMA codes from 
multiple SSs collided or not correctly 
received. T3 timeouts can also occur 
during multichannel operation. On a 
system with multiple uplink channels, 
the SS must attempt initial ranging on 
every suitable uplink channel before 
.marking the downlink channel 
unusable and moving to the next 
available downlink channel. 
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1 


F 


Mark DL 
channel unusable 
(Note] 
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Start T1 9 
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f Scan for a 
Downlink 
Channel 
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Timeout 
T3 



j RNG 


-RSP 
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r 




Abort 



Random Backoff 
[note] 



1 


r 


MarkDL 




channel unusable 




^ 


r 


Start T19 ' 





Yes 




No 



Go to minimum 
power 



Increase power 



Move to 
designated 
frequency 



Scan for 
DL-MAP 





Success or Continue 



Adjust local 
parameters per 
RNG-RSP 




Yes 



Continue 



•^Success or" 
continue? 



Success 



Wait for Initial 

Ranging 
opportunity 







Send \ 
RNG-REQ . \ 




r 



Wait for 
RNG-RSP 



Figure 86— CDMA Initial Ranging— SS (part 2) 
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Initial Ranging Code 
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(continue or 
abort) j 
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Send \ 
RNG-RSP \ 
(success) / 





Send 
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BW allocation 



NOTE — Means ranging is within the tolerable limits of the BS, 

Figure 87— CDMA Initial Ranging— BS 
6.3.10.3.2 Periodic ranging and automatic adjustments 

An SS that wishes to perform periodic ranging shall take the following steps: 

— The SS, shall choose randomly a Ranging Slot (with the use of a binary truncated exponent 
algorithm to avoid possible re-collisions) at the time to perform the ranging, then it chooses 
randomly a Ranging Code (from the Periodic Ranging domain) and sends it to the BS (as a CDMA 
code). 

— The BS cannot tell which SS sent the CDMA ranging request; therefore, upon successfully receiving 
a CDMA Ranging Code, the BS broadcasts a Ranging Response message that advertises the 
received Ranging Code as well as the ranging slot (OFDMA symbol number, subchannel, etc.) 
where the CDMA Ranging code has been identified. This information is used by the SS that sent the 
CDMA ranging code to identify the Ranging Response message that corresponds to its ranging 
request. The Ranging Response message contains all the needed adjustment (e.g., time, power, and 
possibly frequency corrections) and a status notification. 

— Upon receiving a Ranging Response message with continue status, the SS shall continue the ranging 
process with further ranging codes randomly chosen from the Periodic Ranging domain. 

— Using the OFDMA ranging mechanism, the periodic ranging timer is controlled by the SS, not the 
BS. 

— The BS may send an unsolicited RNG-RSP as a response to a CDMA-based bandwidth-request or 
any other data transmission from the SS. 
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When the SS receives an unsolicited RNG-RSP message, it shall reset the periodic ranging timer and adjust 
the parameters (timing and power, etc.) as notified in the RNG-RSP message. 



CDMA 
Periodic Ranging - 
BS 



RNG-RSP without 
corrections 
(Note 2) 




r i 






\ 


j Done 




Done 




V J 




V 


/ 



NOTES 

1 — Means ranging is within the tolerable limits of the BS. 

2— In this case, the RNG-RSP message is sent in order to initiate the SS to send ranging code. 

Figure 88— Periodic CDMA ranging— BS 
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Figure 89— Periodic ranging— Received ranging code— BS 
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Timeout T3 
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Error: 
Re-initialize MAC 
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Error: 
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Figure 90— Periodic CDMA ranging— SS 

Table 122 describes the ranging adjustment process. 

Table 122— CDMA periodic Ranging and automatic adjustments procedure 



BS 




SS 


[time to send next map] 






Send map containing Ranging 


.... UL-MAP; > 




Region Information 








< Ranging Code 


Transmit randomly selected 




Ranging code in a randomly 






selected Ranging Slot from 






available Ranging Region 
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Table 122— CDMA periodic Ranging and automatic adjustments procedure (continued) 



BS 




SS 


[Receive Ranging Code] 






Send Ranging Response with 
Time & Power Corrections and 
original Ranging Code and 
Ranging Slot 


RNG-RSP > 




Status = Continue 




Receive RNG-RSP message 
with Ranging Code and Rang- 
ing Slot matching sent values 
Adjust Time & Power 
parameters 

State = Continue 


[time to send next map] 






Send map containing Ranging 
Region Information 


UL-MAP > 




[Receive Ranging Code] 


< Ranging Code 


Transmit randomly selected 
Ranging code in a randomly 
selected Ranging Slot from 
available Ranging Region 


Send Ranging Response with 
Time & Power Corrections and 
original Ranging Code and 
Ranging Slot 


RNG-RSP > 




Status = Success 




Receive RNG-RSP message 
with Ranging Code and Rang- 
ing Slot matching sent values 
Adjust Time & Power 
parameters 

State = Success 



6.3.11 Update of channel descriptors 

The channel descriptors (i.e., the UCD and DCD messages) are transmitted at regular intervals by the BS. 
Each descriptor contains the Configuration Change Count, which shall remain unchanged as long as the 
channel descriptor remains unchanged. All UL-MAP and DL-MAP messages allocating transmissions and 
receptions using burst profiles defined in a channel descriptor with a given Configuration Change Count 
value shall have a UCD/DCD Count value equal to the Configuration Change Count of the corresponding 
channel descriptor. 

The procedure to transition from one generation of the channel descriptors (and, as a consequence, the set of 
burst profiles) to the next is shown in Table 123 and Table 124, for the uplink and downlink, respectively. 
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The Configuration Change Count shall be incremented by 1 modulo 256 for every new generation of 
channel descriptor. After issuing a DL-MAP or UL-MAP message with the Configuration Change Count 
equal to that of the new generation, the old channel descriptor ceases to exist and the BS shall not issue UL- 
MAP and DL-MAP messages referring to it. When transitioning from one generation to the next, the BS 
shall schedule the transmissions of the UCD and DCD messages in such a way that each terminal has the 
possibility to hear it at least once. 



Table 123 — UCD update 



BS 




SS 


send UL-MAP with UCD Count = i 


UL-MAP > 


descriptor with UCD Count = i 
previously stored in SS 




< data 


Transmit using burst profiles 
defined in UCD with 
Configuration Change Count = i 


[change of channel descriptor com- 
manded! 






send UL-MAP with UCD Count = i 


UL-MAP > 


descriptor with Configuration 
Change Count = / still stored in 
SS 


send UCD message with Configura- 
tion Change Count = (i+1 MOD 
256) 


UCD > 


store new descriptor with 
Configuration Change Count = 
(i+1 MOD 256) 






Transmit using burst profiles 
defined in UCD with 
Configuration Change Count = i 


send UL-MAP with UCD Count = i 


UL-MAP > 


descriptor with Configuration 
Change Count = i still stored in 
SS 


Retransmit UCD message with 
Configuration Change Count = (i+1 
MOD 256) 

[UCD transition interval start] 


UCD > 


store new descriptor with 
Configuration Change Count = 
(i+1 MOD 256) 




< data 


Transmit using burst profiles 
denned in utu witn 
Configuration Change Count = i 


send UL-MAP with UCD Count = i 


UL-MAP > 


descriptor with UCD Count = i 
previously stored in SS 




< _ data 


Transmit using burst profiles 
defined in UCD with 
Configuration Change Count = i 


[UCD transition interval expired] 






send UL-MAP with UCD Count = 
(i+1 MOD 256) 


UL-MAP > 


delete descriptor with 
Configuration Change Count = i 




< data 


Transmit using burst profiles 
defined in UCD with 
Configuration Change Count = 
(i+1 MOD 256) ! 
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Table 124 — DCD update 



DC 






ss 


send DL-MAP with DCD Count 
= i 


DL-MAP-- 


> 


descriptor with Configuration 
Change Count = i previously 
stored in SS 


Transmit using burst profiles 
defined in DCD with Configura- 
tion Change Count = / 




> 


Rprpivp iiQi'no hiirct nrnfilpc 

defined in DCD with 
Configuration Change Count = j 


[change of channel descriptor 
commanded] 








send DL-MAP with DCD Count 
= i 


DL-MAP—- 


> 


descriptor with Configuration 
Change Count = / still stored in 
SS 


send DCD message with Configu- 
ration Change Count = (7+7 MOD 
256) 


DCD 


> 


store new descriptor with 
Configuration Change Count = 
fi+ J MOD 2^ 


Transmit using burst profiles 
defined in DCD with 
Configuration Change Count = i 


data 


> 


Receive using burst profiles 
defined in DCD with 
Configuration Change Count = i 


send DL-MAP with DCD Count 
= t 


DL-MAP— 


> 


descriptor with Configuration 
Change Count = i still stored in 
SS 


Retransmit DCD message with 
Configuration Change Count = 

MOD 256) 
[DCD transition interval start] 


DCD 


> 


store new descriptor with Con- 
figuration Change Count = (7+7 
MOD 256) 


Transmit using burst profiles 
defined in DCD with 
Configuration Change Count = i 


data 


> 


Receive using burst profiles 
defined in DCD with 
Configuration Change Count = i 


[DCD transition interval expired] 








send DL-MAP with Configura- 
tion Change Count = (7+7 MOD 
256) 


DL-MAP—- 




delete descriptor with 
Configuration Change Count = / 


Transmit using burst profiles 
defined in PCD with 
Configuration Change Count = 
i+7 


r data 


> 


Receive using burst profiles 
defined in DCD with " 
Configuration Change Count = 
(7+7 MOD 256) 



6.3.12 Assigning SSs to multicast groups 

The BS may add an SS to a Multicast polling group by sending an MCA-REQ message with the Join 
command. Upon receiving an MCA-REQ message, the SS shall respond by sending an MCA-RSP message. 
The protocol is shown in Figure 91 and Figure 92. 
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Figure 91— Multicast polling assignment— SS 
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Figure 92— Multicast polling assignment— BS 
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6.3.13 Establishment of multicast connections 

The BS may establish a downlink multicast service by creating a connection with each SS to be associated 
with the service. Any available traffic CID value may be used for the service (i.e., there are no dedicated 
CIDs for multicast transport connections). To ensure proper multicast operation, the CID used for the service 
is the same for all SSs on the same channel that participate in the connection. The SSs need not be aware that 
the connection is a multicast connection. The data transmitted on the connection with the given CID shall be 
received and processed by the MAC of each involved SS. Thus, each multicast SDU is transmitted only once 
per BS channel. Since a multicast connection is associated with a service flow, it is associated with the QoS 
and traffic parameters for that service flow. 

ARQ is not applicable to multicast connections. 

If a downlink multicast connection is to be encrypted, each SS participating in the connection shall have an 
additional security association (SA), allowing that connection to be encrypted using keys that are 
independent of those used for other encrypted transmissions between the SSs and the BS. 

6.3.14 QoS 

This standard defines several QoS related concepts. These include the following: 

a) Service Flow QoS Scheduling 

b) Dynamic Service Establishment 

c) Two-phase Activation Model 

6.3.14.1 Theory of operation 

The various protocol mechanisms described in this document may be used to support QoS for both uplink 
and downlink traffic through the SS and the BS. This subclause provides an overview of the QoS protocol 
mechanisms and their part in providing end-to-end QoS. 

The requirements for QoS include the following: 

.a) A configuration and registration function for preconfiguring SS-based QoS service flows and traffic 
parameters. 

b) A signaling function for dynamically establishing QoS-enabled service flows and traffic parameters. 

c) Utilization of MAC scheduling and QoS traffic parameters for uplink service flows. 

d) Utilization of QoS traffic parameters for downlink service flows. 

e) Grouping of service flow properties into named Service Classes, so upper-layer entities and external 
applications (at both the SS and BS) may request service flows with desired QoS parameters in a 
globally consistent way. 

The principal mechanism for providing QoS is to associate packets traversing the MAC interface into a 
service flow as identified by the CID. A service flow is a unidirectional flow of packets that is provided a 
particular QoS. The SS and BS provide this QoS according to the QoS Parameter Set defined for the service 
flow. 

The primary purpose of the QoS features defined here is to define transmission ordering and scheduling on 
the air interface. However, these features often need to work in conjunction with mechanisms beyond the air 
interface in order to provide end-to-end QoS or to police the behavior of SSs. 
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Service flows exist in both the uplink and downlink direction and may exist without actually being activated 
to carry traffic. All service flows have a 32-bit SFID; admitted and active service flows also have a 16-bit 
CID. 

6.3.14.2 Service flows 

A service flow is a MAC transport service that provides unidirectional transport of packets either to uplink 
packets transmitted by the SS or to downlink packets transmitted by the BS. 12 A service flow is 
characterized by a set of QoS Parameters such as latency, jitter, and throughput assurances. In order to 
standardize operation between the SS and BS, these attributes include details of how the SS requests uplink 
bandwidth allocations and the expected behavior of the BS uplink scheduler. 

A service flow is partially characterized by the following attributes: 13 

a) Service Flow ID: An SFID is assigned to each existing service flow. The SFID serves as the 
principal identifier for the service flow in the network. A service flow has at least an SFID and an 
associated direction. 

b) CID: Mapping to an SFID that exists only when the connection has an admitted or active service 
flow. 

c) ProvisionedQoSParamSet: A QoS parameter set provisioned via means outside of the scope of this 
standard, such. as the network management system. 

d) AdmittedQoSParamSet: Defines a set of QoS parameters for which the BS (and possibly the SS) are 
reserving resources. The principal resource to be reserved is bandwidth, but this also includes any 
other memory or time-based resource required to subsequently activate the flow. 

e) ActiveQoSParamSet: Defines a set of QoS parameters defining the service actually being provided 
to the service flow. Only an Active service flow may forward packets. 

f) Authorization Module: A logical function within the BS that approves or denies every change to 
QoS Parameters and Classifiers associated with a service flow. As such, it defines an "envelope" 
that limits the possible values of the AdmittedQoSParamSet and ActiveQoSParamSet. 

The relationship between the QoS Parameter Sets is as shown in Figure 93 and Figure 94. The 
ActiveQoSParamSet is always a subset 14 of the AdmittedQoSParamSet, which is always a subset of the 
authorized "envelope." In the dynamic authorization model, this envelope is determined by the 
Authorization Module (labeled as the AuthorizedQoSParamSet). In the provisioned authorization model, 
this envelope is determined by the ProvisionedQoSParamSet.lt is useful to think of three types of service 
flows: 

1) Provisioned: This type of service flow is known via provisioning by, for example, the network 
management system. Its AdmittedQoSParamSet and ActiveQoSParamSet are both null. 



A service flow, as defined here, has no direct relationship to the concept of a "flow" as defined by the IETF Integrated Services 
(intserv) Working Group (IETF RFC 22 12). An intserv flow is a collection of packets sharing transport-layer endpoints. Multiple 
intserv flows can be served by a single service flow. 

13 Some attributes are derived from the above attribute list. The Service Class Name is an attribute of the ProvisionedQoSParamSet. The 
activation state of the service flow is determined by the ActiveQoSParamSet. If the ActiveQoSParamSet is null, then the service flow is 
inactive. 

14 To say that QoS Parameter Set A is a subset of QoS Parameter Set B the following shall be true for all QoS Parameters in A and B: 
if (a smaller QoS parameter value indicates less resources, e.g., Maximum Traffic Rate) 
A is a subset of B if the parameter in A is less than or equal to the same parameter in B 
if (a larger QoS parameter value indicates less resources, e.g., Tolerated Grant Jitter) 
A is a subset of B if the parameter in A is greater than or equal to the same parameter in B 
if (the QoS parameter is not quantitative, e.g., Service Flow Scheduling Type) 
A is a subset of B if the parameter in A is equal to the same parameter in B 
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Figure 94— Dynamic authorization model "envelopes" 
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2) Admitted: This type of service flow has resources reserved by the BS for its 
AdmittedQoSParamSet, but these parameters are not active (i.e., its ActiveQoSParamSet is 
null). Admitted Service Flows may have been provisioned or may have been signalled by some 
other mechanism. 

3) Active: This type of service flow has resources committed by the BS for its 
ActiveQoSParamSet, (e.g., is actively sending maps containing unsolicited grants for a UGS- 
based service flow). Its ActiveQoSParamSet is non-null. 

6.3.14.3 Object model 



The major objects of the architecture are represented by named rectangles in Figure 95. Each object has a 
number of attributes; the attribute names that uniquely identify it are underlined. Optional attributes are 
denoted with brackets. The relationship between the number of objects is marked at each end of the 
association line between the objects. For example, a service flow may be associated with from 0 to N (many) 
PDUs, but a PDU is associated with exactly one service flow. The service flow is the central concept of the 
MAC protocol. It is uniquely identified by a 32-bit (SFID). Service flows may be in either the uplink or 
downlink direction. Admitted and active service flows are mapped to a 16-bit CID. 

Outgoing user data is submitted to the MAC SAP by a CS process for transmission on the MAC interface. 
The information delivered to the MAC SAP includes the CID identifying the connection across which the 
information is delivered. The service flow for the connection is mapped to MAC connection identified by 
the CID. 

The Service Class is an optional object that may be implemented at the BS. It is referenced by an ASCII 
name, which is intended for provisioning purposes. A Service Class is defined in the BS to have a particular 
QoS Parameter Set. The QoS Parameter Sets of a service flow may contain a reference to the Service Class 
Name as a "macro" that selects all of the QoS parameters of the Service Class. The service flow QoS 
Parameter Sets may augment and even override the QoS parameter settings of the Service Class, subject to 
authorization by the BS. 
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Figure 95— Theory of Operation Object Model 
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6.3.14.4 Service classes 

The Service Class serves the following purposes: 

a) It allows operators, who so wish, to move the burden of configuring service flows from the 
provisioning server to the BS. Operators provision the SSs with the Service Class Name; the 
implementation of the name is configured at the BS. This allows operators to modify the 
implementation of a given service to local circumstances without changing SS provisioning. For 
example, some scheduling parameters may need to be tweaked differently for two different BSs to 
provide the same service. As another example, service profiles could be changed by time of day. 

b) It allows higher-layer protocols to create a service flow by its Service Class Name. For example, 
telephony signaling may direct the SS to instantiate any available provisioned service flow of class 
"G711." 

NOTE — Service classes are merely identifiers for a specific set of QoS parameter set values. Hence, the use of service 
classes is optional. A service identified by a service class is treated no differently, once established, than a service that 
has the same QoS parameter set explicitly specified. 

Any service flow may have its QoS Parameter Set specified in any of three ways: 

— By explicitly including all traffic parameters. 

— By indirectly referring to a set of traffic parameters by specifying a Service Class Name. 

— By specifying a Service Class Name along with modifying parameters. 

The Service Class Name is "expanded" to its defined set of parameters at the time the BS successfully 
admits the service flow. The Service Class expansion can be contained in the following BS-originated 
messages: DSA-REQ, DSC-REQ, DSA-RSP, and DSC-RSP. In all of these cases, the BS shall include a 
service flow encoding that includes the Service Class Name and the QoS Parameter Set of the Service Class. 
If an SS-initiated request contained any supplemental or overriding service flow parameters, a successful 
response shall also include these parameters. 

When a Service Class name is given in an admission or activation request, it is possible that the returned 
QoS Parameter Set may change from activation to activation. This can happen because of administrative 
changes to the Service Class's QoS Parameter Set at the BS. If the definition of a Service Class Name is 
changed at the BS (e.g., its associated QoS Parameter Set is modified), it has no effect on the QoS 
Parameters of existing service flows associated with that Service Class. A BS may initiate DSC transactions 
to existing service flows that reference the Service Class Name to affect the changed Service Class 
definition. 

When an SS uses the Service Class Name to specify the Admitted QoS Parameter Set, the expanded set of 
TLV encodings of the service flow shall be returned to the SS in the response message (DSA-RSP or 
DSC-RSP). Use of the Service Class Name later in the activation request may fail if the definition of the 
Service Class Name has changed and the new required resources are not available. Thus, the SS should 
explicitly request the expanded set of TLVs from the response message in its later activation request. 

6.3.14.5 Authorization 

Every change to the service flow QoS Parameters shall be approved by an authorization module. This 
includes every DSA-REQ message to create a new service flow and every DSC-REQ message to change a 
QoS Parameter Set of an existing service flow. Such changes include requesting an admission control 
decision (e.g., setting the AdmittedQoSParamSet) and requesting activation of a service flow (e.g., setting* 
the ActiveQoSParamSet). Reduction requests regarding the resources to be admitted or activated are also 
checked by the authorization module. 
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In the static authorization model, the authorization module stores the provisioned status of all "deferred" 
service flows. Admission and activation requests for these provisioned service flows shall be permitted, as 
long as the Admitted QoS Parameter Set is a subset of the Provisioned QoS Parameter Set, and the Active 
QoS Parameter Set is a subset of the Admitted QoS Parameter Set. Requests to change the Provisioned QoS 
Parameter Set shall be refused, as shall requests to create new dynamic service flows. This defines a static 
system where all possible services are defined in the initial configuration of each SS. 

In the dynamic authorization model, the authorization module also communicates through a separate 
interface to an independent policy server. This policy server may provide the authorization module with 
advance notice of upcoming admission and activation requests, and it specifies the proper authorization 
action to be taken on those requests. Admission and activation requests from an SS are then checked by the 
Authorization Module to ensure that the ActiveQoSParamSet being requested is a subset of the set provided 
by the policy server. Admission and activation requests from an SS that are signalled in advance by the 
external policy server are permitted. Admission and activation requests from an SS that are not presignalled 
by the external policy server may result in a real-time query to the policy server or may be refused. 

Prior to initial connection setup, the BS shall retrieve the Provisioned QoS Set for an SS. This is handed to 
the Authorization Module within the BS. The BS shall be capable of caching the Provisioned QoS Parameter 
Set and shall be able to use this information to authorize dynamic flows that are a subset of the Provisioned 
QoS Parameter Set. The BS should implement mechanisms for overriding this automated approval process 
(such as described in the dynamic authorization model). For example it could: 

a) Deny all requests whether or not they have been preprovisioned. 

b) Define an internal table with a richer policy mechanism but seeded by the Provisioned QoS Set. 

c) Refer all requests to an external policy server. 

6.3.1 4.6 Types of service flows 

It is useful to think about three basic types of service flows. This subclause describes these three types of 
service flows in more detail. However, it is important to note that there are more than just these three basic 
types (see 11.13.4). 

6.3.14.6.1 Provisioned service flows 

A service flow may be provisioned but not immediately activated (sometimes called "deferred"). That is, the 
description of any such service flow contains an attribute that provisions but defers activation and admission 
(see 11.13.4). The network assigns a SFID for such a service flow. The BS may also require an exchange 
with a policy module prior to admission. 

As a result of external action beyond the scope of this specification, the SS may choose to activate a 
provisioned service flow by passing the SFID and the associated QoS Parameter Sets to the BS in the 
DSC-REQ message. If authorized and resources are available, the BS shall respond by mapping the service 
flow to a CID. 

As a result of external action beyond the scope of this specification, the BS may choose to activate a service 
flow by passing the SFID as well as the CID and the associated QoS Parameter Sets to the SS in the DSC- 
REQ message. Such a provisioned service flow may be activated and deactivated many times (through DSC 
exchanges). In all cases, the original SFID shall be used when reactivating the service flow. 

6.3.14.6.2 Admitted service flows 

This protocol supports a two-phase activation model that is often utilized in telephony applications. In the 
two-phase activation model, the resources for a "call" are first "admitted," and then once the end-to-end 
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negotiation is completed (e.g., called party's gateway generates an "off-hook'' event), the resources are 
"activated." The two-phase model serves the following purposes: 

1) conserving network resources until a complete end-to-end connection has been established, 

2) performing policy checks and admission control on resources as quickly as possible, and in 
particular, before informing the far end of a connection request, and 

3) preventing several potential theft-of-service scenarios. 

For example, if an upper-layer service were using UGS, and the addition of upper-layer flows could be 
adequately provided by increasing the Maximum Sustained Traffic Rate QoS parameter, then the following 
procedure might be used. When the first higher-layer flow is pending, the SS issues a DSA-REQ with the 
admitted Maximum Sustained Traffic Rate parameter equal to that required for one higher-layer flow, and 
the active Maximum Sustained Traffic Rate parameter equal to zero. Later when the higher-layer flow 
becomes active, it issues a DSC-REQ with the instance of the active Maximum Sustained Traffic Rate 
parameter equal to that required for one higher-layer flow. Admission control was performed at the time of 
the reservation, so the later DSC-REQ, having the active parameters within the range of the previous 
reservation, is guaranteed to succeed. Subsequent higher-layer flows would be handled in the same way. If 
there were three higher-layer flows establishing connections, with one flow already active, the service flow 
would have admitted Maximum Sustained Traffic Rate equal to that required for four higher-layer flows, 
and active Maximum Sustained Traffic Rate equal to that required for one higher-layer flow. 

An activation request of a service flow where the new ActiveQoSParamSet is a subset of the 
AdmittedQoSParamSet shall be allowed, except in the case of catastrophic failure. An admission request 
where the AdmittedQoSParamSet is a subset of the previous AdmittedQoSParamSet, so long as the 
ActiveQoSParamSet remains a subset of the AdmittedQoSParamSet, shall succeed. 

A service flow that has resources assigned to its AdmittedQoSParamSet, but whose resources are not yet 
completely activated, is in a transient state. It is possible in some applications that a long-term reservation of 
resources is necessary or desirable. For example, placing a telephone call on hold should allow any 
resources in use for the call to be temporarily allocated to other purposes, but these resources shall be 
available for resumption of the call later. The AdmittedQoSParamSet is maintained as "soft state" in the BS; 
this state shall be maintained without releasing the nonactivated resources. Changes may be signaled with a 
DSC-REQ message. 

6.3.14.6.3 Active service flows 

A service flow that has a non-NULL ActiveQoSParamSet is said to be an active service flow. It is requesting 
(according to its Request/Transmission Policy, as in 11.13.12) and being granted bandwidth for transport of 
data packets. An admitted service flow may be activated by providing an ActiveQoSParamSet, signaling the 
resources actually desired at the current time. This completes the second stage of the two-phase activation 
model (see 6.3.14.6.2). 

A service flow may be provisioned and immediately activated. Alternatively, a service flow may be created 
dynamically and immediately activated. In this case, two-phase activation is skipped and the service flow is 
available for immediate use upon authorization. 

6.3.14.7 Service Flow Creation 

The provisioning of service flows is done via means outside of the scope of this standard, such as the 
network management system. During provisioning, a service flow is instantiated, gets a service flow ID and 
a "provisioned" type. For some service flows it may be specified that DSA procedure must be activated by 
Network Entry procedure. Enabling service flows follows the transfer of the operational parameters, as 



224 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



shown in Figure 55. In this case, the service flow type may change to "admitted" or to "active;" in the latter 
case, the Service Flow is mapped onto a certain connection. 

Service flow encodings contain either a full definition of service attributes (omitting defaultable items if 
desired) or a service class name. A service class name is an ASCII string, which is known at the BS and 
which indirectly specifies a set of QoS Parameters. 

Triggers, other than network entry, also may cause creation, admission, or activation of service flows. Such 
triggers lay outside the scope of the standard. 

Capability of handling each specific Service Flow parameter is optional. 

6.3.14.7.1 Dynamic service flow creation 

6.3.14.7.1.1 Dynamic service flow creation— SS-initiated 

Creation of service flows may be initiated by either BS (mandatory capability) or by SS (optional 
capability). 

The SS-initiated protocol is illustrated in Figure 96 and described in detail in 6.3.14.9.3.1. 

A DSA-REQ from an SS contains a service flow reference and QoS Parameter set (marked either for 
admission-only or for admission and activation). 

BS responds with DSA-RSP indicating acceptance or rejection. In the case when rejection was caused by 
presence of non-supported parameter of non-supported value, specific parameter may be included into DSA- 
RSP. 



SS 




Figure 96 — DSA message flow— SS-initiated 
6.3.14.7.1.2 Dynamic service flow creation— BS-initiated 

A DSA-REQ from a BS contains an SFID for either one uplink or one downlink Service flow, possibly its 
associated CID, and a set of active or admitted QoS Parameters. The protocol is illustrated in Figure 97 and 
is described in detail in 6.3.14.9.3.3. 
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SS responds with DSA-RSP indicating acceptance or rejection. In the case when rejection was caused by 
presence of non-supported parameter of non-supported value, specific parameter may be included into DSA- 
RSP. 



6.3.14.8 Dynamic service flow modification and deletion 

In addition to the methods presented in 6.3.14.7 for creating service flows, protocols are defined for 
modifying and deleting service flows; see 6.3.14.9.4 and 6.3.14.9.5. 

Both provisioned and dynamically created service flows are modified with the DSC message, which can 
change the Admitted and Active QoS Parameter sets of the flow. 

A successful DSC transaction changes a service flow's QoS parameters by replacing both the Admitted and 
Active QoS parameter sets. If the message contains only the Admitted set, the Active set is set to null and the 
flow is deactivated. If the message contains neither set ("000" value used for QoS Parameter Set type, see 
11.13.4), then both sets are set to null and the flow is de-admitted. When the message contains both QoS 
parameter sets, the Admitted set is checked first, and if admission control succeeds, the Active set in the 
message is checked against the Admitted set in the message to ensure that it is a subset. If all checks are 
successful, the QoS parameter sets in the message become the new Admitted and Active QoS parameter sets 
for the service flow. If either of the checks fails, the DSC transaction fails and the service flow QoS 
parameter sets are unchanged. 

6.3.14.9 Service flow management 
6.3.14.9.1 Overview 

Service flows may be created, changed, or deleted. This is accomplished through a series of MAC 
management messages referred to as DSA, DSC, and DSD. The DSA messages create a new service flow. 
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The DSC messages change an existing service flow. The DSD messages delete an existing service flow. This 
is illustrated in Figure 98. 

DSC 




Figure 98— Dynamic service flow overview 



The Null state implies that no service flow exists that matches the SFID and/or Transaction ID in a message. 
Once the service flow exists, it is operational and has an assigned SFID. In steady-state operation, a service 
flow resides in a Nominal state. When DSx messaging is occurring, the service flow may transition through 
other states, but remains operational. Since multiple service flows may exist, there may be multiple state 
machines active, one for every service flow. DSx messages only affect those state machines that match the 
SFID and/or Transaction ID. Both the SS and BS shall verify the HMAC-Digest on all DSx messages before 
processing them, and discard any messages that fail. 

Transaction IDs are unique per transaction and are selected by the initiating device (SS or BS). To help 
prevent ambiguity and provide simple checking, the Transaction ID number space is split between the SS 
and BS. The SS shall select its Transaction IDs from the first half of the number space (0x0000 to 0x7FFF). 
The BS shall select its Transaction IDs from the second half of the number space (0x8000 to OxFFFF). 

Each DSx message sequence is a unique transaction with an associated unique transaction identifier. The 
DSA/DSC transactions consist of a request/response/acknowledge sequence. The DSD transactions consist 
of a request/response sequence. The response messages shall return a CC of OK unless some exception 
condition was detected. The acknowledge messages shall return the CC in the response unless a new 
exception condition arises. A more detailed state diagram, including transition states, is shown in Figure 99 
through Figure 105. The detailed actions for each transaction shall be given in the following subclauses. 

6.3.14.9.2 Dynamic Service Flow state transitions 

The Dynamic Service Flow state transition diagram (Figure 99) is the top-level state diagram and controls 
the general service flow state. As needed, it creates transactions, each represented by a Transaction state 
transition diagram, to provide the DSA, DSC, and DSD signaling. Each Transaction state transition diagram 
communicates only with the parent Dynamic Service Flow state transition diagram. The top-level state 
transition diagram filters DSx messages and passes them to the appropriate transaction based on SFID, 
service flow reference number, and Transaction ID. 

There are six different types of transactions, which are locally initiated or remotely initiated for each of the 
DSA, DSC, and DSD messages (Figure 100-Figure 105). Most transactions have three basic states — 
pending, holding, and deleting. The pending state is typically entered after creation and is where the 
transaction is waiting for a reply. The holding state is typically entered once the reply is received. The 
purpose of this state is to allow for retransmissions in case of a lost message, even though the local entity has 
perceived that the transaction has completed. The deleting state is only entered if the service flow is being 
deleted while a transaction is being processed. 
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The flow diagrams provide a detailed representation of each of the states in the Transaction state transition 
diagrams. All valid transitions are shown. Any inputs not shown should be handled as a severe error 
condition. 

With one exception, these state diagrams apply equally to the BS and SS. In the Dynamic Service Flow 
Changing-Local state, there is a subtle difference in the SS and BS behaviors. This is called out in the state 
transition and detailed flow diagrams. 

NOTE— The "Num Xacts" variable in the Dynamic Service Flow state transition diagram is incremented every time the 
top-level state diagram creates a transaction and is decremented every time a transaction terminates. A dynamic service 
flow shall not return to the Null state until it is deleted and all transactions have terminated. 

The inputs for the state diagrams are identified below. 

Dynamic Service Flow state transition diagram inputs from unspecified local, higher level entities: 

a) Add 

b) Change 

c) Delete 

Dynamic Service Flow state transition diagram inputs from DSx Transaction state transition diagrams: 



a) 


DSA Succeeded 


b) 


DSA Failed 


c) 


DSA-ACK Lost 


d) 


DSA Erred 


e) 


DSA Ended 


a) 


DSC Succeeded 


b) 


DSC Failed 


c) 


DSC-ACK Lost 


d) 


DSC Erred 


e) 


DSC Ended 


a) 


DSD Succeeded 


b) 


DSD Erred 


c) 


DSD Ended 



DSx Transaction state transition diagram inputs from the Dynamic Service Flow state transition diagram: 



a) 


SF Add 


b) 


SF Change 


c) 


SF Delete 


a) 


SF Abort Add 


b) 


SF Change-Remote 


c) 


SF Delete-Local 


d) 


SF Delete-Remote 


a) 


SF DSA-ACK Lost 



228 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



lEEEStd 802.16-2004 



b) SF DSC-REQ Lost 

c) SF DSC- ACK Lost 

d) SF DSC-REQ Lost 

a) SF Changed 

b) SF Deleted 

The creation of DSx transactions by the Dynamic Service Flow state transition diagram is indicated by the 
notation: 

DSx - [ Local | Remote ] ( initiaMnput ) 

where initialjnput may be SF Add, DSA-REQ, SF Change, DSC-REQ, SF Delete, or DSD-REQ, 
depending on the transaction type and initiator. 

State transitions (i.e., the lines between states) are labeled with <what causes the transition>/<messages and 
events triggered by the transitions If there are multiple events or messages before the slash "/" separated by 
a comma, any of them can cause the transition. If there are multiple events or messages listed after the slash, 
all of the specified actions shall accompany the transition. 

For example, "DSD-REQ/SF Delete Remote, DSD-Remote(DSD-REQ)" should be read as follows: Once 
DSD-REQ is received, it triggers sending a "SF Delete Remote" event to transactions running for this 
service flow AND starting the "DSD-Remote" transaction and pass the event DSD-REQ to it. 
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DSA Erred/ 
DSD-Local(SF Delete) 



DSA Succeeded / 



DSA Succeeded / 



( DSC-REQ / [BS Only] ) 
( DSA ACK Lost/ 

SF DSC_REQ Lost) 
(DSC ACK Lost/ 

SF DSC-REQ Lost) 



Delete / 
SF Delete-Local 
DSD-Local (SF Delete) 





DSC-REQ / 
SF Change-Remote, 
DSC-Remote( DSC REQ ) 



(DSA Erred/ 
DSD-Local( SF Delete ) ) 
( Delete / SF Delete-Local, 
DSD-Local ( SF Delete) ) 



New DSC-REQ / 
SF DSC-ACK Lost 



( DSC Succeeded / 
SF Changed) 
(DSC Failed/ 
SF Change) 



( DSC Succeeded / 
SF Changed ) 

(DSC Failed/ 
SF Changed) 



( DSC Erred / SF Delete Local 
DSD-Local ( SF Delete) ) 

( Delete / SF Delete-Local, 
DSD-Local ( SF Delete) ) 



. DSC-REQ SF Change-Remote, - — — 

~~~ DSC-Remote( DSC REQ SS Only]) 

(Change/SF Change-Local) ^ 
(SF Change) [BS Only] — — ' 
( DSC-REQ / ) 
(DSA ACK Lost/ 
SF DSD-REQ Lost ) 
(DSC ACK Lost/ 




( DSC Erred / SF Delete Local 
DSD-Local ( SF Delete) ) 
SF DSD-REQ Lost) ( Delete / SF Delete-Local, 
DSD-Local( SF Delete) ) 



DSD-REQ / SF Delete-Remote, DSD-Remote (DSD-REQ) 




DSD Ended && 
Num Xacts == 0/ 



(DSD Succeeded / SF Deleted) 
(DSD Erred / SF Deleted) 



DSD Succeeded / SF Deleted 



Figure 99 — Dynamic Service Flow state transition diagram 
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SF Add / DSA-REQ 




Figure 100— DS A— Locally Initiated Transaction state transition diagram 
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( DSA-REQ / DSX-RVD, DSA-RSP ) 
( DSA-REQ / DSA Failed, DSA-RSP ) 



( Timeout T8 && Retries Available / DSA-RSP) 

( DSA-REQ && Retries Available / DSX-RVD, DSA-RSP ) 

( DSA-REQ && Retries Exhausted / ) 

( SF DSA-ACK Lost && Retries Available / DSA-RSP ) 

( SF DSA-ACK Lost && Retries Exhausted / ) 



( Timeout T8 && Re 
( SF Delete-Remote / DSA Ended ) 




(DSAREQ/) 
( DSA-ACK / ) 



( Timeout T10/ DSA Ended) 
(SF Deleted /DSA Ended) 
( SF Delete-Remote / DSA Ended ) 



Figure 101— DSA— Remotely Initiated Transaction state transition diagram 
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(( Timeout T7 || Timeout T14) && Retries Available / DSC-REQ ) 
( SF DSC-REQ Lost && Retries Available / DSC-REQ ) 
SF DSC-REQ Lost && Retries Exhausted / ) 
(DSX-RVD/) 



((Timeout 77 || Timeout T14) 
&& Retries Exhausted f) 




Figure 102— DSC— Locally Initiated Transaction state transition diagram 
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DSC-REQ / DSX-RVD, DSC-RSP 



( Timeout T8 && Retries Available / DSC-RSP ) 

( DSC-REQ && Retries Available / DSX-RVD, DSC-RSP ) 

( DSC-REQ && Retries Exhausted / ) 

( SF DSC-ACK Lost && Retries Available / DSC-RSP ) 

( SF DSC-ACK Lost && Retries Exhausted / ) 



( Timeout T8 && Regies 
( SF Delete-Remote 
(SF Change Local/) 




( Timeout T10 / DSC Ended ) 
( SF Deleted / DSC Ended ) 
( SF Delete-Remote / DSC Ended ) 
(SF Change Local/) [BS only] 



Figure 103— DSC— Remotely Initiated Transaction state transition diagram 
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Figure 104— DSD— Locally Initiated Transaction state transition diagram 
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DSD-REQ / DSD Succeeded. DSD-RSP 



I Holding \ \ 



DSD-REQ / DSD-RSP 



( Timeout T10 / DSD Ended ) 
( SF Deleted / DSD Ended ) 



© 



Figure 105— DSD— Remotely Initiated Transaction state transition diagram 



6.3.14.9.3 DSA 

6.3.14.9.3.1 SS-initiated DSA 

An SS wishing to create either an uplink or downlink service flow sends a request to the BS using a DSA- 
REQ message. The BS checks the integrity of the message and, if the message is intact, sends a message 
received (DSX-RVD) response to the SS. The BS checks the SS's authorization for the requested service and 
whether the QoS requirements can be supported, generating an appropriate response using a DSA-RSP 
message. The SS concludes the transaction with an acknowledgment message (DSA-ACK). This process is 
illustrated in Table 125. 



Table 125— DSA initiated from SS 



SS 




BS 


New service flow needed 






Check if resources are available 






Send DSA-REQ 

Set Timers T7 andT14 


— DSA-REQ--> 


Receive DSA-REQ 


Timer T14 Stops 


<« DSX-RVD-- 


DSA-REQ integrity valid 

Check whether SS is authorized for 
Service 3 
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Table 125 — DSA initiated from SS (continued) 



SS 


BS 




v-.necK wneiner service now i^oo can oe 




suppKjneu 




Create SFID 




If uplink AdmittedQoSParamSet is 




non-null, map service flow to CID 




I r 1 1 r\l ml/ 1 A 1/0^^ C? Do tvi *v% C^t i 0 nAn mill 

II upiinK Acuvei^ooraramoet is non-nun, 




Enable reception of data on new uplink 




service flow 


Receive DSA-RSP <--DSA-RSP— 


Send DSA-RSP 


TimprT7 Qtnnc 
inner i / oiupa 




If ActiveQoSParamSet is non-null, Enable 




transmission and/or reception of data on 




new service flow 




Send DSA-ACK — DSA-ACK--> 


Receive DSA-ACK 




If downlink ActiveQoSParamSet is 




non-null, Enable transmission of data on 




new downlink service flow 



Authorization happens prior to the DSA-REQ being received by the BS. The details of BS signalling to anticipate a DSA-REQ are 
beyond the scope of this standard. 



6.3.1 4.9.3.2 BS-initiated DSA 

A BS wishing to establish either an uplink or a downlink dynamic service flow with an SS performs the 
following operations. The BS checks the authorization of the destination SS for the requested class of 
service and to determine whether the QoS requirements can be supported. If the service can be supported, 
the BS generates a new SFID with the required class of service and informs the SS using a DSA-REQ 
message. If the SS checks that it can support the service, it responds using a DSA-RSP message. The 
transaction completes with the BS sending the acknowledge message (DSA-ACK). This process is 
illustrated in Table 126. 



Table 126— DSA initiated from BS 



SS 




BS 






New service flow required for SS 






Check whether SS is authorized for Service 






Check whether service flow(s) QoS can be 
supported 






Create SFID 






If AdmittedQoSParamSet is non-null, map 
service flow to CID 


Receive DSA-REQ 


<--DSA-REQ— 


Send DSA-REQ ! 
Set Timer T7 
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Table 126— DSA initiated from BS (continued) 



ss 


BS 


Confirm that SS can support service flow 




Ada DOwnunK oriu \ii present 




Enable reception on any new downlink 
service flow 

SendDSA-RSP ~DSA-RSP--> 


Receive DSA-RSP 
Timer T7 Stops 

Enable transmission (downlink) or reception 
(uplink) of data on new service flow 


Receive DSA-ACK <-DSA-ACK— 


Send DSA-ACK 


Enable transmission on new. uplink 
service flow 
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6.3.14.9.3.3 DSA state transition diagrams 

DSA state transition diagrams are shown in Figure 106-Figure 114. 



f DSA-Local 
Begin 



1 




\ SFAdd 




\ 


r 


) 


DSA-REQ 




F 


Start timer 
T7 


\ 


r 


[SS Only] 
Start timer 
T14 


\ 


F 


Save transmitted 
DSA-REQ 
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Figure 106— DSA— Locally Initiated Transaction Begin state flow diagram 
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Figure 107— DSA— Locally Initiated Transaction DSA-RSP Pending state flow diagram 
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Figure 110— DSA— Locally Initiated Transaction Deleting Service Flow state flow diagram 
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Figure 111— DSA— Remotely Initiated Transaction Begin state flow diagram 
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Figure 112— DSA— Remotely Initiated Transaction DSA-ACK Pending state flow diagram 
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6.3.14.9.4 DSC 

The DSC set of messages is used to modify the flow parameters associated with a service flow. Specifically, 
DSC can modify the service flow Specification. 

A single DSC message exchange can modify the parameters of either one downlink service flow or one 
uplink service flow. 

To prevent packet loss, any required bandwidth change is sequenced between the SS and BS. 

The BS controls both uplink and downlink scheduling. The timing of scheduling changes is independent of 
direction AND whether it is an increase or decrease in bandwidth. The BS always changes scheduling on 
receipt of a DSC-REQ (SS-initiated transaction) or DSC-RSP (BS-initiated transaction). 

The BS also controls the downlink transmit behavior. The change in downlink transmit behavior is always 
coincident with the change in downlink scheduling (i.e., BS controls both and changes both simultaneously). 

The SS controls the uplink transmit behavior. The timing of SS transmit behavior changes is a function of 
which device initiated the transaction AND whether the change is an "increase" or "decrease" in bandwidth. 

If an uplink service flow's bandwidth is being reduced, the SS reduces its payload bandwidth first and then 
the BS reduces the bandwidth scheduled for the service flow. If an uplink service flow's bandwidth is being 
increased, the BS increases the bandwidth scheduled for the service flow first and then the SS increases its 
payload bandwidth. 

Any service flow can be deactivated with a DSC command by sending a DSC-REQ message, referencing 
the SFID, and including a null ActiveQoSParamSet. However, if a Basic, Primary Management, or 
Secondary Management Connection of an SS is deactivated, that SS is deregistered and shall re-register. 
Therefore, care should be taken before deactivating such service flows. If a service flow that was 
provisioned is deactivated, the provisioning information for that service flow shall be maintained until the 
service flow is reactivated. 

An SS shall have only one DSC transaction outstanding per service flow. If it detects a second transaction 
initiated by the BS, the SS shall abort the transaction it initiated and allow the BS-initiated transaction to 
complete. 

A BS shall have only one DSC transaction outstanding per service flow. If it detects a second transaction 
initiated by the SS, the BS shall abort the transaction that the SS initiated and allow the BS-initiated 
transaction to complete. 

The following service flow parameters may not be changed, and shall not be present in the DSC-REQ or 
DSC-RSP messages: 

— Service Flow Scheduling Type 

— Request/Transmission Policy 

— Convergence Sublayer Specification 

— Fixed-Length versus Variable-Length SDU Indicator 

— SDU Size 

— ATM switching (ATM Services only) 

— ARQ parameters, in accordance with individual TLV definitions 

NOTE — Currently anticipated applications would probably control a service flow through either the SS or BS, and not 
both. Therefore, the case of a DSC being initiated simultaneously by the SS and BS is considered as an exception 
condition and treated as one. 
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6.3.14.9.4.1 SS-initiated DSC 

An SS that needs to change a service flow definition performs the following operations. 

The SS informs the BS using a DSC-REQ. The BS checks the integrity of the message and, if the message is 
intact, sends a message received (DSX-RVD) response to the SS. The BS shall decide if the referenced 
service flow can support this modification. The BS shall respond with a DSC-RSP indicating acceptance or 
rejection In the case when rejection was caused by presence of non-supported parameter of non-supported 
value, specific parameter may be included into DSC-RSP. The SS reconfigures the service flow if 
appropriate, and then shall respond with a DSC-ACK. This process is illustrated in Table 127. 



Table 127— SS-initiated DSC 
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Send DSC-REQ 
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DSC_REQ integrity valid 
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Receive DSC-RSP 
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Modify service flow 

Adjust Payload Bandwidth 


Receive DSC-ACK 


< DSC-ACK 


Send DSC-ACK 


Decrease Channel Bandwidth if 




0 



6.3.14.9.4.2 BS-initiated DSC 

A BS that needs to change a service flow definition performs the following operations. 

The BS shall decide if the referenced service flow can support this modification. If so, the BS informs the SS 
using a DSC-REQ. The SS checks that it can support the service change, and shall respond using a 
DSC-RSP indicating acceptance or rejection. In the case when rejection was caused by presence of non- 
supported parameter of non-supported value, specific parameter may be included into DSC-RSP. The BS 
reconfigures the service flow if appropriate, and then shall respond with a DSC-ACK. This process is 
illustrated in Table 128. 

6.3.14.9.4.3 DSC state transition diagrams 

DSC state transition diagrams are shown in Figure 115-Figure 123. 
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Figure 115— DSC— Locally Initiated Transaction Begin state flow diagram 
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Figure 118— DSC— Locally Initiated Transaction Retries Exhausted state flow diagram 
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Figure 119— DSC— Locally Initiated Transaction Deleting Service Flow state flow diagram 
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Figure 120— DSC— Remotely Initiated Transaction Begin state flow diagram 
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Figure 121— DSC— Remotely Initiated Transaction DSC-ACK Pending state flow diagram 
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Figure 122— DSC— Remotely Initiated Transaction Holding Down state flow diagram 



DSC-Remote 

Deleting 
Service Flow 



SF Deleted, 
SF Delete-Remote 



Timeout T10 



DSC-REQ, 
DSC-ACK 



Stop T10 Timer 



DSC-Remote 

Deleting 
Service Flow 




Figure 123— DSC— Remotely Initiated Transaction Deleting Service Flow state 

flow diagram 



Copyright ©2004 IEEE. All rights reserved. 



257 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS PART 16: 



6.3.14.9.5 Connection release 

Any service flow can be deleted with the DSD messages. When a service flow is deleted, all resources 
associated with it are released. If a service flow for a provisioned service is deleted, the ability to re-estoblish 
the service flow for that service is network management dependent. Therefore, care should be taken before 
deleting such service flows. However, the deletion of a provisioned service flow shall not cause an SS to 
reinitialize. 

6.3.14.9.5.1 SS-initiated DSD 

An SS wishing to delete a service flow generates a delete request to the BS using a DSD-REQ message. The 
BS removes the service flow and generates a response using a DSD-RSP message. This process is illustrated 
in Table 129. Only one service flow can be deleted per DSD-REQ. 



Table 129— DSD-initiated from SS 



SS 




BS 


Service flow no longer needed 






Delete service flow 






Send DSD-REQ 


— DSD-REQ--> 


Receive DSD-REQ 
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<~DSD-RSP— 
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6.3.14.9.5.2 BS-initiated DSD 

A BS wishing to delete a dynamic service flow generates a delete request to the associated SS using a DSD- 
REQ. The SS removes the service flow and generates a response using a DSD-RSP. This process is 
illustrated in Table 130. Only one service flow can be deleted per DSD-REQ. 



Table 130— DSD-initiated from BS 
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258 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



6.3.14.9.5.3 DSD state transition diagrams 

DSD state transition diagrams are shown in Figure 124-Figure 128. 
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Figure 124— DSD— Locally Initiated Transaction Begin state flow diagram 
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Figure 125— DSD— Locally Initiated Transaction DSD-RSP Pending state flow diagram 
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Figure 126— DSD— Locally Initiated Transaction Holding Down state flow diagram 
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Figure 127— DSD— Remotely Initiated Transaction Begin state flow diagram 
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Figure 128— DSD— Remotely Initiated Transaction Holding Down state flow diagram 

6.3.15 DFS for license-exempt operation 
6.3.15.1 Introduction 

DFS is mandatory for license-exempt operation. Systems should detect and avoid primary users. Further, the 
use of channel selection algorithms is required, which result in uniform channel spreading across a 
minimum number of channels. This specification is intended to be compliant with the regulatory 
requirements set forth in ERC/DEC/(99)23 [BIO]. The timing parameters used for DFS are specified by 
each regulatory administration. 

The DFS procedures provide for: 

— Testing channels for primary users (6.3.15.2) 

— Discontinuing operations after detecting primary users (6.3:15.3) 

— Detecting primary users (6.3.15.4) 

— Scheduling for channel testing (6.3.15.5). 

— Requesting and reporting of measurements (6.3.15.6) 

— Selecting and advertising a new channel (6.3.15.7) 



6.3.15.2 Testing channels for primary users 

A BS or SS shall not use a channel that it knows contains primary users or has not been tested recently for 
the presence of primary users. A BS shall test for the presence of primary users for at least the following: 

— Startup Test Period before operating in a new channel if the channel has not been tested for primary 
users for at least Startup Test Period during the last Startup Test Valid. 
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— Startup Test Period before operating in a new channel if a channel was previously determined to 
contain primary users during the last Startup Test Valid. 

— Operating Test Period (where the period is only accumulated during testing) of each Operating 
Test Cycle period while operating in a channel. Testing may occur in quiet periods or during normal 
operation. 

An SS may start operating in a new channel without following the above start-up testing procedures if: 

— The SS moves to the channel as a result of the receipt of a Channel Switch Announcement from the 
BS. 

— The SS is initializing with a BS that is not currently advertising, using the Channel Switch 
Announcement that it is about to move to a new channel. 

A BS may start operating in a new channel without following the above start-up testing procedures if it has 
learned from another BS by means outside the scope of this standard that it is usable. 

6.3.15.3 Discontinuing operations after detecting primary users 

If a BS or an SS is operating in a channel and detects primary users, which interference might be caused in 
the channel, it shall discontinue any transmission of the following: 

— MAC PDUs carrying data within Max Data Operations Period. 

— MAC PDUs carrying MAC Management messages within Management Operations Period. 

6.3.15.4 Detecting primary users 

Each BS and SS shall use a method to detect primary users operating in a channel that satisfies the 
regulatory requirements. The particular method used to perform the primary user detection is outside the 
scope of this specification. 

6.3.15.5 Scheduling for channel testing 

A BS may measure one or more channels itself and request any SS to measure one or more channels on its 
behalf, either in a quiet period or during normal operation. 

To request the SSs to measure one channel, the BS shall include in the DL-MAP a Report Measurement IE 
as specified in 8.3.6.2.3. The BS that requests the SSs to perform a measurement shall not transmit MAC 
PDUs to any SS during the measurement interval. If the channel measured is the operational channel, the BS 
shall not schedule any uplink transmissions from SSs to take place during.the measurement period. 

Upon receiving a DL-MAP with the DFS Measurement IE, an SS shall start to measure the indicated 
channel no later than Max. Channel Switch Time after the start of the measurement period. An SS may 
stop the measurement no sooner than Max. Channel Switch Time before the expected start of the next 
frame or the next scheduled uplink transmission (of any SS). If the channel to be measured is the operating 
channel, Max. Channel Switch Time shall be equal to the value of RTG, as specified in Table 358. Max. 
Channel Switch Time shall not exceed 2 ms. 

6.3.1 5.6 Requesting and reporting of measurements 

The SS shall, for each measured channel, keep track of the following information: 

Frame Number of the frame during which the first measurement was made 

— Accumulated time measured 
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— Existence of a Primary User on the channel 

— Whether a WirelessHUMAN using the same PHY system was detected on the measured channel 

— Whether unknown transmissions [such as radio local area network (RLAN) transmissions] were 
detected on the channel 

The BS may request a measurement report by sending a REP-REQ message. This is typically done after the 
aggregated measurement time for one or more channels exceeds the regulatory required measurement time. 
Upon receiving a REP-REQ the SS shall reply with a REP-RSP message and reset its measurement counters 
for each channel on which it reported. 

If the SS detects a primary user on the channel it is operating during a measurement interval or during 
normal operation it shall immediately cease to send any user data and send at the earliest possible 
opportunity an unsolicited REP-RSP. The BS shall provide transmission opportunities for sending an 
unsolicited REP-RSP frequently enough to meet regulatory requirements. The SS may also send, in an 
unsolicited fashion, a REP-RSP when non-primary user interference is detected above a threshold value. 

6.3.15.7 Selecting and advertising a new channel 

A BS may decide to stop operating in a channel at any time. The algorithm used to decide to stop operating 
in a channel is outside the scope of this standard, but shall satisfy any regulatory requirements. 

A BS may use a variety of information, including information learned during SS initialization and 
information gathered from measurements undertaken by the BS and the SSs, to assist in the selection of the 
new channel. The algorithm to choose a new channel is not standardized but shall satisfy any regulatory 
requirements, including uniform spreading rules and channel testing rules. If a BS would like to move to a 
new channel, a channel supported by all SSs in the sector should be selected. 

A BS shall inform its associated SSs of the new channel using the Channel Nr in the DCD message. The new 
channel shall be used starting from the frame with the number given by the Channel Switch Frame Number 
in the DCD message. The BS shall not schedule any transmissions during the last Max. Channel Switch 
Time before the channel change is to take place. 

The uplink burst profiles used on the old channel defined shall be considered valid also for the new channel, 
i.e., the BS need not define new uplink Burst Profiles when changing channels. When operating in license- 
exempt bands, the BS shall not send the Frequency (Type=3) parameter as a part of UCD message. 

6.3.16 MAC Management message tunneling in Mesh Mode 

In Mesh networks during network entry, certain MAC message protocols take place between entities 
separated by multiple hops. In these cases, the Sponsor Node shall relay the MAC messages from the New 
Node acting as the SS to the peer performing the duties of the PMP BS. The sponsor shall also relay the 
messages from the BS entity to the New Node. 

The Sponsor shall tunnel the MAC messages received from the New Node (SS), listed in Table 131 over 
UDP as shown in Figure 129, to the entity performing the BS part of the protocol. The sponsor shall also 
extract the MAC messages from the UDP packets arriving from the BS entity and transmit them over the air 
to the New Node. 
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Table 131— MAC Management messages tunneled over UDP during network entry 



Message 


Action of sponsor 


Direction of message 


PKM-REQ:Auth Request 


Tunnel 


SS to BS 


PKM-REQ:Auth Info 


Tunnel 


SS to BS 


PKM-RSP:Auth Reply 


Extract 


BS to SS 


PKM-RSP:Auth Reject 


Extract 


BS to SS 


REG-REQ 


Tunnel 


SS to BS 


REG-RSP 


Extract 


BS to SS 



| IP header(s) 


UDP Header 


Tunnel 
subheader 


MAC message including headers I 



Figure 129— MAC over UDP/IP tunneling 



The format of the Tunnel subheader is defined in Table 132. 



Table 132— Tunnel subheader Format 



Syntax 


Size 


Notes 


Tunnel_Subheader() { 






Type 


1 byte 


0 = Reserved 

1 = WirelessMAN MAC header 
2-255 - Reserved 


} 







Also, MAC messages may need to be tunneled end-to-end in cases when the protocol takes place between 
peers separated by several hops. The packet format in Figure 129 shall be used in these cases with the 
Tunnel subheader format defined in Table 132. 

6.3.17 MAC support for H-ARQ 

Hybrid automatic repeat request (H-ARQ) scheme is an optional part of the MAC and can be enabled on a 
per-terminal basis. H-ARQ may be supported only for the OFDMA PHY. The per-terminal H-ARQ and 
associated parameters shall be specified and negotiated during initialization procedure. A burst cannot have 
a mixture of H-ARQ and non-H-ARQ traffic. 

One or more MAC PDUs can be concatenated and an H-ARQ packet formed by adding a CRC to the PHY 
burst. Figure 130 shows how the H-ARQ encoder packet is constructed. 
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-MAC PDU (variable length) 



-MAC PDU (variable length) 



MAC HDR 



Payload 



MAC HDR 



Payload 



CRC 



Parity bits 



H-ARQ packet mapped onto PHY burst 



Figure 130 — Construction of H-ARQ encoder packet 



Each H-ARQ packet is encoded according to the PHY specification, and four subpackets are generated from 
the encoded result. A subpacket identifier (SPID) is used to distinguish the four subpackets. In case of down- 
link communication, a BS can send one of the subpackets in a burst transmission. Because of the redundancy 
among the subpackets, SS can correctly decode the original encoder packet even before it receives all four 
subpackets. Whenever receiving the first subpacket, the SS attempts to decode the original encoder packet 
from it. If it succeeds, the SS sends an ACK to the BS, so that the BS stops sending additional subpackets of 
the encoder packet. Otherwise, the SS sends a NAK, which causes the BS to transmit one subpacket selected 
from the four. These procedures go on until the SS successfully decodes the encoder packet. When the SS 
receives more than one subpacket, it tries to decode the encoder packet from ever-received subpackets. 



The rule of subpacket transmission is as follows, 



1) At the first transmission, BS shall send the subpacket labeled '00'. 

2) BS may send one among subpackets labeled '00', '01\ '10', or '11' in any order. 

3) BS can send more than one copy of any subpacket, and can omit any subpacket except the subpacket 
labeled '00'. 



In order to specify the start of a new transmission, one-bit H-ARQ identifier sequence number (AI_SN) is 
toggled on every successful transmission of an encoder packet on the same H-ARQ channel. If the AI_SN 
changes, the receiver treats the corresponding subpacket as a subpacket belongs to a new encoder packet, 
and discards ever-received subpackets with the same ARQ identifier. 

The H-ARQ scheme is basically a stop-and-wait protocol. The ACK is sent by the SS after a fixed delay 
(synchronous ACK) defined by H-ARQ DL ACK delay offset, which is specified in DCD message. Timing 
of retransmission, however, is flexible and corresponds to the asynchronous part of the H-ARQ. The ACK/ 
NAK is sent by the BS using the H-ARQ Bitmap IE, and sent by an SS using the fast feedback UL 
subchannel. 



The H-ARQ scheme supports multiple H-ARQ channels per a connection, each of which may have an 
encoder packet transaction pending. The number of H-ARQ channels in use is determined by BS. These 
ARQ channels are distinguished by an H-ARQ channel identifier (ACID). The ACID for any subpackets can 
be uniquely identified by the control information carried in the MAPs. 

H-ARQ can be used to mitigate the effect of channel and interference fluctuation. H-ARQ renders 
performance improvement due to SNR gain and time diversity achieved by combining previously 
erroneously decoded packet and retransmitted packet, and due to additional coding gain by Incremental 
Redundancy (IR). 
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6.3.17.1 Subpacket generation 

H-ARQ operates at the FEC block level. The FEC encoder is responsible for generating the H-ARQ sub- 
packets, as defined in the relevant PHY section. The subpackets are combined by the receiver FEC decoder 
as part of the decoding process. 

6.3.17.2 DUUL ACK/NAK signaling 

For DL/UL H-ARQ, fast ACK/NAK signaling is necessary. For the fast ACK/NAK signaling of DL H-ARQ 
channel, a dedicated PHY layer ACK/NAK channel is designed in UL. For the fast ACK/NAK signaling of 
UL fast feedback, H-ARQ ACK message is designed. 

6.3.17.3 H-ARQ parameter signaling 

The parameters for each subpacket should be signaled independent of the subpacket burst itself. The 
parameters for each subpacket include 

— SPID: The BS shall set this field to the subpacket identifier for the subpacket transmission. 

— ACID: The BS shall set this field to the ARQ channel identifier for the subpacket transmission. 

— AI_SN: This toggles between "0" and "1" on successfully transmitting each encoder packet with the 
same ARQ channel. 

For the signaling of those parameters, H-ARQ Allocation IE is defined and the IE is to be placed in a DL- 
MAP or UL-MAP for a burst where H-ARQ is used. 

6.3.17.4 CQICH Operations 

This subclause describes the operation scenarios and requirements of CQICH, which is designed for H-ARQ 
enabled SS. After an SS turns on its power, the only appropriate subchannels that can be allocated to the 
MSS are normal subchannels. To determine the M/C level of normal subchannels, the average CINR 
measurement is enough for the BS to determine the M/C levels of uplink and downlink. As soon as the BS 
and the SS know the capabilities of both entities modulation and coding, the BS may allocate a CQICH 
subchannel using a CQICH Control IE. Then, the MSS reports the average CINR of the BS preamble. From 
then on, the BS is able to determine the M/C level. A CINR measurement is quantized into 32 levels and 
encoded into 5 information bits. 

At any time, the BS may de-allocate the SS' CQICH by putting another CQICH Control IE with Duration 
d = 0000. Before the CQICH life timer (which is set at the receipt of the CQICH Control IE expires) sending 
another CQICH Control IE overwrites all the information related to the CQICH such as Allocation Index, 
Period, Frame offset, and Duration. Hence, unless the BS refreshes the timer, the SS should stop reporting as 
soon as the timer expires. However, in case of sending the MAP IE for re-allocation or deallocation, the BS 
should make sure if the previous CQICH is released before it is re-allocated to another SS. 

The SS sends the REP-RSP message in an unsolicited fashion to BS to trigger Band AMC operation. The 
triggering conditions are given by TLV encodings in UCD messages. The REP-RSP (see 11.12 for the TLV 
encodings) includes the CINR measurements of five best bands. Only when an SS reports its BS the CINR 
measurements of Band AMC channels, its logical definition is made differently, as follows. If the number of 
bands is 48 (2048 FFT in 20 MHz), the two contiguous bands are paired and renumbered the same as a 24 
band system. Then, if the LSB of an SS MAC address is 1, it only uses the odd-numbered bands. If not, it 
only uses the even-numbered bands. Hence, for example, the LSB of an SS MAC address is 1, (4m+2, 
4m+3) bands are paired and the paired band is the m-th band of the SS. Similarly, for an even-numbered SS, 
(4m, 4m+l) bands are paired and the paired band is the m-th band of the SS. 
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The BS acknowledges the trigger by allocating Band AMC subchannels. From the next frame when the SS 
sent the REP-RSP, the SS starts reporting the differential of CINR five selected bands (increment: 1 and 
decrement: 0 with a step of 1 dB) on its CQICH. If the BS does not allocate the Band AMC subchannels 
within the specified delay (CQICH Band AMC Transition Delay) in the UCD message, the SS reports the 
updated average CINR of the preamble for normal subchannel allocations. 

When the BS wants to trigger the transition to Band AMC mode or update the CINR reports, it sends the 
REP-REQ message (see 11.11 for the TLV encodings). When the SS receives the message, it replies with 
REP-RSP. When the BS receives the REP-RSP, it should synchronize the selection of bands reported and 
their CINR. Unless the BS allocates normal subchannels, the SS reports the differential increment compared 
to the most up-to-date report from the next CQI reporting frame. 
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7. Security sublayer 

Security provides subscribers with privacy across the fixed broadband wireless network. It does this by 
encrypting connections between SS and BS. 

In addition, security provides operators with strong protection from theft of service. The BS protects against 
unauthorized access to these data transport services by enforcing encryption of the associated service flows 
across the network. Privacy employs an authenticated client/server key management protocol in which the 
BS, the server, controls distribution of keying material to client SS. Additionally, the basic privacy 
mechanisms are strengthened by adding digital-certificate-based SS authentication to its key management 
protocol. 

If during capabilities negotiation, the SS specifies that it does not support IEEE 802.16 security, step of 
authorization and key exchange shall be skipped. The BS, if provisioned so, shall consider the SS 
authenticated; otherwise, the SS shall not be serviced. Neither key exchange nor data encryption performed. 

7.1 Architecture 

Privacy has two component protocols as follows: 

a) An encapsulation protocol for encrypting packet data across the fixed BWA network. This protocol 
defines (1) a set of supported cryptographic suites, i.e., pairings of data encryption and 
authentication algorithms, and (2) the rules for applying those algorithms to a MAC PDU payload. 

b) A key management protocol (PKM) providing the secure distribution of keying data from BS to SS. 
Through this key management protocol, the SS and the BS synchronize keying data; in addition, the 
BS uses the protocol to enforce conditional access to network services. 

7.1.1 Packet data encryption 

Encryption services are defined as a set of capabilities within the MAC security sublayer. MAC Header 
information specific to encryption is allocated in the generic MAC header format. 

Encryption is always applied to the MAC PDU payload; the generic MAC header is not encrypted. All MAC 
management messages described in 6.3.2.3 shall be sent in the clear to facilitate registration, ranging, and 
normal operation of the MAC. 

The format of MAC PDUs carrying encrypted packet data payloads is specified in 6.3.3.6. 

7.1.2 Key management protocol 

An SS uses the PKM protocol to obtain authorization and traffic keying material from the BS, and to support 
periodic reauthorization and key refresh. The key management protocol uses X.509 digital certificates 
(IETF RFC 3280), the RSA public-key encryption algorithm [PKCS #1], and strong encryption algorithms 
to perform key exchanges between SS and BS. 

The PKM protocol adheres to a client/server model, where the SS, a PKM "client," requests keying material, 
and the BS, a PKM "server," responds to those requests, ensuring that individual SS clients receive only 
keying material for which they are authorized. The PKM protocol uses MAC management messaging, i.e., 
PKM-REQ and PKM-RSP messages defined in 6.3.2.3. 

The PKM protocol uses public-key cryptography to establish a shared secret (i.e., an AK) between the SS 
and the BS. The shared secret is then used to secure subsequent PKM exchanges of TEKs. This two-tiered 
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mechanism for key distribution permits refreshing of TEKs without incurring the overhead of computation- 
intensive public-key operations. 

A BS authenticates a client SS during the initial authorization exchange. Each SS carries a unique X.509 
digital certificate issued by the SS's manufacturer. The digital certificate contains the SS's Public Key and 
SS MAC address. When requesting an AK, an SS presents its digital certificate to the BS. The BS verifies 
the digital certificate, and then uses the verified Public Key to encrypt an AK, which the BS then sends back 
to the requesting SS. 

The BS associates an SS's authenticated identity to a paying subscriber, and hence to the data services that 
subscriber is authorized to access. Thus, with the AK exchange, the BS establishes an authenticated identity 
of a client SS and the services (i.e., specific TEKs) the SS is authorized to access. 

Since the BS authenticates the SS, it can protect against an attacker employing a cloned SS, masquerading as 
a legitimate subscriber's SS. The use of the X.509 certificates prevents cloned SSs from passing fake 
credentials onto a BS. 

All SSs shall have factory-installed RSA private/public key pairs or provide an internal algorithm to 
generate such key pairs dynamically. If an SS relies on an internal algorithm to generate its RSA key pair, 
the SS shall generate the key pair prior to its first AK exchange, described in 7.2.1. All SSs with factory- 
installed RSA key pairs shall also have factory-installed X.509 certificates. All SSs that rely on internal 
algorithms to generate an RSA key pair shall support a mechanism for installing a manufacturer-issued 
X.509 certificate following key generation. 

The PKM protocol is defined in detail in 7.2. 

7.1 .3 Security Associations 

A Security Association (SA) is the set of security information a BS and one or more of its client SSs share in 
order to support secure communications across the IEEE Std 802.16 network. Three types of SAs are 
defined: Primary, Static, and Dynamic. Each manageable SS establishes a Primary Security association 
during the SS initialization process. Static SAs are provisioned within the BS. Dynamic SAs are established 
and eliminated, on the fly, in response to the initiation and termination of specific service flows. Both Static 
and Dynamic SAs can be shared by multiple SSs. 

An SA's shared information shall include the Cryptographic Suite employed within the SA. The shared 
information may include TEKs and Initialization Vectors. The exact content of the SA is dependent on the 
SA's Cryptographic Suite. 

SAs are identified using SAIDs. 

Each manageable SS shall establish an exclusive Primary SA with its BS. The SAID of any SS's Primary SA 
shall be equal to the Basic CID of that SS. 

Using the PKM protocol, an SS requests from its BS an SA's keying material. The BS shall ensure that each 
client SS only has access to the SAs it is authorized to access. 

An SA's keying material [e.g., Data Encryption Standard (DES) key and CBC Initialization Vector] has a 
limited lifetime. When the BS delivers SA keying material to an SS, it also provides the, SS with that 
material's remaining lifetime. It is the responsibility of the SS to request new keying material from the BS 
before the set of keying material that the SS currently holds expires at the BS. Should the current keying 
material expire before a new set of keying material is received, the SS shall perform network entry as 
described in 6.3.9. The PKM protocol specifies how SS and BS maintain key synchronization. 
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7.1.4 Mapping of connections to SAs 

The following rules for mapping connections to SAs apply: 

1) All Transport Connections shall be mapped to an existing SA. 

2) Multicast Transport Connections may be mapped to any Static or Dynamic SA. 

3) The Secondary Management Connection shall be mapped to the Primary S A. 

4) The Basic and the Primary Management connections shall not be mapped to an S A. 

The actual mapping is achieved by including the SAID of an existing S A in the DSA-xxx messages together 
with the CID. No explicit mapping of Secondary Management Connection to the Primary SA is required. 

7.1.5 Cryptographic Suite 

A Cryptographic Suite is the SA's set of methods for data encryption, data authentication, and TEK 
exchange. A Cryptographic Suite is specified as described in 11.9.14. The Cryptographic Suite shall be one 
of the ones listed in Table 378. 

7.2 PKM protocol 

7.2.1 SS authorization and AK exchange overview 

SS authorization, controlled by the Authorization state machine, is the process of 

a) The BS authenticating a client SS's identity. 

b) The BS providing the authenticated SS with an AK, from which a key encryption key (KEK) and 
message authentication keys are derived. 

c) The BS providing the authenticated SS with the identities (i.e., the SAIDs) and properties of primary 
and static SAs the SS is authorized to obtain keying information for. 

After achieving initial authorization, an SS periodically seeks reauthorization with the BS; reauthorization is 
also managed by the SS's Authorization state machine. An SS must maintain its authorization status with the 
BS in order to be able to refresh aging TEKs. TEK state machines manage the refreshing of TEKs. 

An SS begins authorization by sending an Authentication Information message to its BS. The 
Authentication Information message contains the SS manufacturer's X.509 certificate, issued by the 
manufacturer itself or by an external authority. The Authentication Information message is strictly 
informative; i.e., the BS may choose to ignore it. However, it does provide a mechanism for a BS to learn the 
manufacturer certificates of its client SS. 

The SS sends an Authorization Request message to its BS immediately after sending the Authentication 
Information message. This is a request for an AK, as well as for the SAIDs identifying any Static Security 
SAs the SS is authorized to participate in. The Authorization Request includes 

a) A manufacturer-issued X.509 certificate. 

b) A description of the cryptographic algorithms the requesting SS supports; an SS's cryptographic 
capabilities are presented to the BS as a list of cryptographic suite identifiers, each indicating a 
particular pairing of packet data encryption and packet data authentication algorithms the SS 
supports. 

c) The SS's Basic CID. The Basic CID is the first static CID the BS assigns to an SS during initial 
ranging— the primary SAID is equal to the Basic CID. 
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In response to an Authorization Request message, a BS validates the requesting SS's identity, determines the 
encryption algorithm and protocol support it shares with the SS, activates an AK for the SS, encrypts it with 
the SS's public key, and sends it back to the SS in an Authorization Reply message. The authorization reply 
includes: 

a) An AK encrypted with the SS's public key. 

b) A 4-bit key sequence number, used to distinguish between successive generations of AKs. 

c) A key lifetime. 

d) The identities (i.e., the SAIDs) and properties of the single primary and zero or more static SAs the 
SS is authorized to obtain keying information for. 

While the Authorization Reply shall identify Static SAs in addition to the Primary SA whose SAID matches 
the requesting SS's Basic CID, the Authorization Reply shall not identify any Dynamic SAs. 

The BS, in responding to an SS's Authorization Request, shall determine whether the requesting SS, whose 
identity can be verified via the X.509 digital certificate, is authorized for basic unicast services, and what 
additional statically provisioned services (i.e., Static SAIDs) the SS's user has subscribed for. Note that the 
protected services a BS makes available to a client SS can depend upon the particular cryptographic suites 
the SS and the BS share support for. 

An SS shall periodically refresh its AK by reissuing an Authorization Request to the BS. Reauthorization is 
identical to authorization with the exception that the SS does not send Authentication Information messages 
during reauthorization cycles. The description of the authorization state machine in 7.2.4 clearly indicates 
when Authentication Information messages are sent. 

To avoid service interruptions during reauthorization, successive generations of the SS's AKs have 
overlapping lifetimes. Both SS and BS shall be able to support up to two simultaneously active AKs during 
these transition periods. The operation of the Authorization state machine's Authorization Request 
scheduling algorithm, combined with the BS's regimen for updating and using a client SS's AKs (see 7.4), 
ensures that the SS can refresh TEK keying information without interruption over the course of the SS's 
reauthorization periods. 

7.2.2 TEK exchange overview 

7.2.2.1 TEK exchange overview for PMP topology 

Upon achieving authorization, an SS starts a separate TEK state machine for each of the SAIDs identified in 
the Authorization Reply message. Each TEK state machine operating within the SS is responsible for 
managing the keying material associated with its respective SAID. TEK state machines periodically send 
Key Request messages to the BS, requesting a refresh of keying material for their respective SAIDs. 

The BS responds to a Key Request with a Key Reply message, containing the BS's active keying material 
for a specific SAID. 

The TEK is encrypted using appropriate KEK derived from the AK. 

Note that at all times the BS maintains two active sets of keying material per SAID. The lifetimes of the two 
generations overlap such that each generation becomes active halfway through the life of it predecessor and 
expires halfway through the life of its successor. A BS includes in its Key Replies both of an SAID's active 
generations of keying material. 

The Key Reply provides the requesting SS, in addition to the TEK and CBC initialization vector, the 
remaining lifetime of each of the two sets of keying material. The receiving SS uses these remaining 
lifetimes to estimate when the BS will invalidate a particular TEK, and therefore when to schedule future 
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Key Requests such that the SS requests and receives new keying material before the BS expires the keying 
material the SS currently holds. 

The operation of the TEK state machine's Key Request scheduling algorithm, combined with the BS's 
regimen for updating and using an SAID's keying material (see 7.4), ensures that the SS will be able to 
continually exchange encrypted traffic with the BS. 

A TEK state machine remains active as long as 

a) The SS is authorized to operate in the BS's security domain, i.e., it has a valid AK, and 

b) The SS is authorized to participate in that particular SA, i.e., the BS continues to provide fresh 
keying material during rekey cycles. 

The parent Authorization state machine stops all of its child TEK state machines when the SS receives from 
the BS an Authorization Reject during a reauthorization cycle. Individual TEK state machines can be started 
or stopped during a reauthorization cycle if an SS's Static SAID authorizations changed between successive 
re-authorizations. 

Communication between Authorization and TEK state machines occurs through the passing of events and 
protocol messaging. The Authorization state machine generates events (i.e., Stop, Authorized, Authorization 
Pending, and Authorization Complete events) that are targeted at its child TEK state machines. TEK state 
machines do not target events at their parent Authorization state machine. The TEK state machine affects the 
Authorization state machine indirectly through the messaging a BS sends in response to an SS's requests: a 
BS may respond to a TEK machine's Key Requests with a failure response (i.e., Authorization Invalid 
message) to be handled by the Authorization state machine. 

7.2.2.2 TEK exchange overview for Mesh Mode 

Upon achieving authorization, a Node starts for each Neighbor a separate TEK state machine for each of the 
SAIDs identified in the Authorization Reply message. Each TEK state machine operating within the Node is 
responsible for managing the keying material associated with its respective SAID. The Node is responsible 
for maintaining the TEKs between itself and all nodes it initiates TEK exchange with. Its TEK state 
machines periodically send Key Request messages to the Neighbors of the node, requesting a refresh of 
keying material for their respective SAIDs. 

The Neighbor replies to a Key Request with a Key Reply message, containing the BS's active keying 
material for a specific SAID. 

The TEK in the Key Reply is encrypted, using the node's public key found in the SS -Certificate attribute. 

Note that at all times the node maintains two active sets of keying material per SAID per neighbor. The life- 
times of the two generations overlap such that each generation becomes active halfway through the life of its 
predecessor and expires halfway through the life of its successor. A neighbor includes in its Key Replies 
both of an SAID's active generations of keying material. 

The Key Reply provides the requesting Node, in addition to the TEK, the remaining lifetime of each of the 
two sets of keying material. The receiving Node uses these remaining lifetimes to estimate when the 
Neighbor invalidates a particular TEK, and therefore when to schedule future Key Requests. The transmit 
regime between the initiating Node and the Neighbor provides for seamless key transition. 

7.2.3 Security capabilities selection 

As part of their authorization exchange, the SS provides the BS with a list of all the cryptographic suites 
(pairing of data encryption and data authentication algorithms) the SS supports. The BS selects from this list 
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a single cryptographic suite to employ with the requesting SS's primary SA. The Authorization Reply the 
BS sends back to the SS includes a primary SA-Descriptor that, among other things, identifies the 
cryptographic suite the BS selected to use for the SS's primary SA. A BS shall reject the authorization 
request if it determines that none of the offered cryptographic suites are satisfactory. 

The Authorization Reply also contains an optional list of static SA-Descriptors; each static SA-Descriptor 
identifies the cryptographic suite employed within the SA. The selection of a static SA's cryptographic suite 
is typically made independent of the requesting SS's cryptographic capabilities. A BS may include in its 
Authorization Reply static SA-Descriptors identifying cryptographic suites the requesting SS does not 
support; if this is the case, the SS shall not start TEK state machines for static SAs whose cryptographic 
suites the SS does not support. 

7.2.4 Authorization state machine 

The Authorization state machine consists of six states and eight distinct events (including receipt of 
messages) that can trigger state transitions. The Authorization finite state machine (FSM) is presented below 
in a graphical format, as a state flow model (Figure 131), and in a tabular format, as a state transition matrix 
(Table 133). 

The state flow diagram depicts the protocol messages transmitted and internal events generated for each of 
the model's state transitions; however, the diagram does not indicate additional internal actions, such as the 
clearing or starting of timers, that accompany the specific state transitions. Accompanying the state 
transition matrix is a detailed description of the specific actions accompanying each state transition; the state 
transition matrix shall be used as the definitive specification of protocol actions associated with each state 
transition. 

The following legend applies to the Authorization State Machine flow diagram depicted in Figure 131. 

a) Ovals are states. 

b) Events are in italics. 

c) Messages are in normal font. 

d) State transitions (i.e., the lines between states) are labeled with <what causes the 
transition>/<messages and events triggered by the transitions So "timeout/ Auth Request" means 
that the state received a "timeout" event and sent an Authorization Request ("Auth Request") 
message. If there are multiple events or messages before the slash "/" separated by a comma, any of 
them can cause the transition. If there are multiple events or messages listed after the slash, all of the 
specified actions shall accompany the transition. 
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Table 133— Authorization FSM state transition matrix 
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The Authorization state transition matrix presented in Table 133 lists the six Authorization machine states in 
the topmost row and the eight Authorization machine events (includes message receipts) in the leftmost 
column. Any cell within the matrix represents a specific combination of state and event, with the next state 
(the state transitioned to) displayed within the cell. For example, cell 4-B represents the receipt of an 
Authorization Reply (Auth Reply) message when in the Authorize Wait (Auth Wait) state. Within cell 4-B is 
the name of the next state, "Authorized." Thus, when an SS's Authorization state machine is in the Auth 
Wait state and an Auth Reply message is received, the Authorization state machine will transition to the 
Authorized state. In conjunction with this state transition, several protocol actions shall be taken; these are 
described in the listing of protocol actions, under the heading 4-B, in 7.2.4.5. 

A shaded cell within the state transition matrix implies that either the specific event cannot or should not 
occur within that state, and if the event does occur, the state machine shallignore it. For example, if an Auth 
Reply message arrives when in the Authorized state, that message should be ignored (cell 4-C). The SS may, 
however, in response to an improper event, log its occurrence, generate an SNMP event, or take some other 
vendor-defined action. These actions, however, are not specified within the context of the Authorization 
state machine, which simply ignores improper events. 

7.2.4.1 States 

a) Start: This is the initial state of the FSM. No resources are assigned to or used by the FSM in this 
state — e.g., all timers are off, and no processing is scheduled. 

b) Authorize Wait (Auth Wait): The SS has received the "Communication Established" event indicating 
that it has completed basic capabilities negotiation with the BS. In response to receiving the event, 
the SS has sent both an Authentication Information and an Auth Request message to the BS and is 
waiting for the reply. 

c) Authorized: The SS has received an Auth Reply message that contains a list of valid SAIDs for this 
SS. At this point, the SS has a valid AK and SAID list. Transition into this state triggers the creation 
of one TEK FSM for each of the SS's privacy-enabled SAIDs. 

d) Reauthorize Wait (Reauth Wait): The SS has an outstanding reauthorization request. The SS was 
either about to expire (see Authorization Grace Time in Table 343) its current authorization or 
received an indication (an Authorization Invalid message from the BS) that its authorization is no 
longer valid. The SS sent an Auth Request message to the BS and is waiting for a response. 

e) Authorize Reject Wait (Auth Reject Wait): The SS received an Authorization Reject (Auth Reject) 
message in response to its last Auth Request. The Auth Reject's error code indicated the error was 
not of a permanent nature. In response to receiving this reject message, the SS set a timer and 
transitioned to the Auth Reject Wait state. The SS remains in this state until the timer expires. 

f) Silent: The SS received an Auth Reject message in response to its last Auth Request. The Auth 
Reject's error code indicated the error was of a permanent nature. This triggers a transition to the 
Silent state, where the SS is not permitted to pass subscriber traffic. The SS shall, however, respond 
to management messages from the BS issuing the Perm Auth Reject. 

7.2.4.2 Messages 

Note that the message formats are defined in detail in 6.3.2.3.9. 

Authorization Request (Auth Request): Request an AK and list of authorized SAIDs. Sent from SS to BS. 

Authorization Reply (Auth Reply): Receive an AK and list of authorized, static SAIDs. Sent from BS to SS. 
The AK is encrypted with the SS's public key. 

Authorization Reject (Auth Reject): Attempt to authorize was rejected. Sent from the BS to the SS. 
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Authorization Invalid (Auth Invalid): The BS may send an Authorization Invalid message to a client SS as 
follows: 

a) An unsolicited indication, or 

b) A response to a message received from that SS. 

In either case, the Auth Invalid message instructs the receiving SS to re-authorize with its BS. 

The BS responds to a Key Request with an Auth Invalid message if (1) the BS does not recognize the SS as 
being authorized (i.e., no valid AK associated with SS) or (2) verification of the Key Request's keyed 
message digest (in HMAC-Digest attribute) failed. Note that the Authorization Invalid event, referenced in 
both the state flow diagram and the state transition matrix, signifies either the receipt of an Auth Invalid 
message or an internally generated event. 

Authentication Information (Auth Info): The Auth Info message contains the SS manufacturer's X.509 
Certificate, issued by an external authority. The Auth Info message is strictly an informative message the SS 
sends to the BS; with it, a BS may dynamically learn the manufacturer certificate of client SS. Alternatively, 
a BS may require out-of-band configuration of its list of manufacturer certificates. 

7.2.4.3 Events 

Communication Established: The Authorization state machine generates this event upon entering the Start 
state if the MAC has completed basic capabilities negotiation. If the basic capabilities negotiation is not 
complete, the SS sends a Communication Established event to the Authorization FSM upon completing 
basic capabilities negotiation. The Communication Established event triggers the SS to begin the process of 
getting its AK and TEKs. 

Timeout: A retransmission or wait timer timed out. Generally a request is resent. 

Authorization Grace Timeout (Auth Grace Timeout): The Authorization Grace timer timed out. This timer 
fires a configurable amount of time (the Authorization Grace Time) before the current authorization is 
supposed to expire, signalling the SS to reauthorize before its authorization actually expires. The 
Authorization Grace Time takes the default value from Table 343 or may be specified in a configuration 
setting within the Auth Reply message. 

Reauthorize (Reauth): SS's set of authorized static SAIDs may have changed. This event is generated in 
response to an SNMP set and meant to trigger a reauthorization cycle. 

Authorization Invalid (Auth Invalid): This event is internally generated by the SS when there is a failure 
authenticating a Key Reply or Key Reject message, or externally generated by the receipt of an Auth Invalid 
message, sent from the BS to the SS. A BS responds to a Key Request with an Auth Invalid if verification of 
the request's message authentication code fails. Both cases indicate BS and SS have lost AK 
synchronization. 

A BS may also send to an SS an unsolicited Auth Invalid message, forcing an Auth Invalid event. 

Permanent Authorization Reject (Perm Auth Reject): The SS receives an Auth Reject in response to an Auth 
Request. The error code in the Auth Reject indicates the error is of a permanent nature. What is interpreted 
as a permanent error is subject to administrative control within the BS. Auth Request processing errors that 
can be interpreted as permanent error conditions include the following: 

a) Unknown manufacturer (do not have CA certificate of the issuer of the SS Certificate). 

b) Invalid signature on SS certificate. 
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c) ASN.l parsing failure. 

d) Inconsistencies between data in the certificate and data in accompanying PKM data attributes. 

e) Incompatible security capabilities. 

When an SS receives an Auth Reject indicating a permanent failure condition, the Authorization State 
machine moves into a Silent state, where the SS is not permitted to pass subscriber traffic. The SS shall, 
however, respond to management messages from the BS issuing the Perm Auth Reject. The SS shall also 
issue an SNMP Trap upon entering the Silent state. 

Authorization Reject (Auth Reject): The SS receives an Auth Reject in response to an Auth Request. The 
error code in the Auth Reject does not indicate the failure was due to a permanent error condition. As a 
result, the SS's Authorization state machine shall set a wait timer and transition into the Auth Reject Wait 
State. The SS shall remain in this state until the timer expires, at which time it shall reattempt authorization. 

NOTE — The following events are sent by an Authorization state machine to the TEK state machine: 

[TEK] Stop: Sent by the Authorization FSM to an active (non-START state) TEK FSM to terminate the 
FSM and remove the corresponding SAID's keying material from the SS's key table. 

[TEK] Authorized: Sent by the Authorization FSM to a nonactive (START state), but valid TEK FSM. 

[TEK] Authorization Pending (Auth Fend): Sent by the Authorization FSM to a specific TEK FSM to place 
that TEK FSM in a wait state until the Authorization FSM can complete its reauthorization operation. 

[TEK] Authorization Complete (Auth Comp): Sent by the Authorization FSM to a TEK FSM in the 
Operational Reauthorize Wait (Op Reauth Wait) or Rekey Reauthorize Wait (Rekey Reauth Wait) states to 
clear the wait state begun by a TEK FSM Authorization Pending event. 

7.2.4.4 Parameters 

All configuration parameter values take the default values from Table 343 or may be specified in the Auth 
Reply message. 

Authorize Wait Timeout (Auth Wait Timeout): Timeout period between sending Authorization Request 
messages from Auth Wait state (see 1 1 .9. 19.2). 

Authorization Grace Timeout (Auth Grace Timeout): Amount of time before authorization is scheduled to 
expire that the SS starts reauthorization (see 11.9.19.3). 

Authorize Reject Wait Timeout (Auth Reject Wait Timeout): Amount of time an SS's Authorization FSM 
remains in the Auth Reject Wait state before transitioning to the Start state (see 11.9.19.7). 

7.2.4.5 Actions 

Actions taken in association with state transitions are listed by <event> (<rcvd message>) --> <state> below: 
1-A Start (Communication Established) -» Auth Wait 

a) Send Auth Info message to BS 

b) Send Auth Request message to BS 

c) Set Auth Request retry timer to Auth Wait Timeout 
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2-B Auth Wait (Auth Reject) -» Auth Reject Wait 

a) Clear Auth Request retry timer 

b) Set a wait timer to Auth Reject Wait Timeout 

2- D Reauth Wait (Auth Reject) -> Auth Reject Wait 

a) Clear Auth Request retry timer 

b) Generate TEK FSM Stop events for all active TEK state machines 

c) Set a wait timer to Auth Reject Wait Timeout 

3- B Auth Wait (Perm Auth Reject) -> Silent 

a) Clear Auth Request retry timer 

b) Disable all forwarding of SS traffic 

3- D Reauth Wait (Perm Auth Reject) -> Silent 

a) Clear Auth Request retry timer 

b) Generate TEK FSM Stop events for all active TEK state machines 

c) Disable all forwarding of SS traffic 

4- B Auth Wait (Auth Reply) -> Authorized 

a) Clear Auth Request retry timer 

b) Decrypt and record AK delivered with Auth Reply 

c) Start TEK FSMs for all SAIDs listed in Authorization Reply (provided the SS supports the 
cryptographic suite that is associated with an SAID) and issue a TEK FSM Authorized event for 
each of the new TEK FSMs 

d) Set the Authorization Grace timer to go off "Authorization Grace Time" seconds prior to the 
supplied AK's scheduled expiration 

4-D Reauth Wait (Auth Reply) -> Authorized 

a) Clear Auth Request retry timer 

b) Decrypt and record AK delivered with Auth Reply 

c) Start TEK FSMs for any newly authorized SAIDs listed in Auth Reply (provided the SS supports the 
cryptographic suite that is associated with the new SAID) and issue TEK FSM Authorized event for 
each of the new TEK FSMs 

d) Generate TEK FSM Authorization Complete events for any currently active TEK FSMs whose 
corresponding SAIDs were listed in Auth Reply 

e) Generate TEK FSM Stop events for any currently active TEK FSMs whose corresponding SAIDs 
were not listed in Auth Reply 

f) Set the Authorization Grace timer to go off "Authorization Grace Time" seconds prior to the 
supplied AK's scheduled expiration 
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5-B Auth Wait (Timeout) H> Auth Wait 

a) Send Auth Info message to BS 

b) Send Auth Request message to BS 

c) Set Auth Request retry timer to Auth Wait Timeout 

5-D Reauth Wait (Timeout) -> Reauth Wait 

a) Send Auth Request message to BS 

b) Set Auth Request retry timer to Reauth Wait Timeout 

5- E Auth Reject Wait (Timeout) Start 

a) No protocol actions associated with state transition 

6- C Authorized (Auth Grace Timeout) -> Reauth Wait 

a) Send Auth Request message to BS 

b) Set Auth Request retry timer to Reauth Wait Timeout 

7- C Authorized (Auth Invalid) -> Reauth Wait 

a) Clear Authorization Grace timer 

b) Send Auth Request message to BS 

c) Set Auth Request retry timer to Reauth Wait Timeout 

d) If the Auth Invalid event is associated with a particular TEK FSM, generate a TEK FSM 
Authorization Pending event for the TEK state machine responsible for the Auth Invalid event (i.e., 
the TEK FSM that either generated the event, or sent the Key Request message the BS responded to 
with an Auth Invalid message) 

7- D Reauth Wait (Auth Invalid) -» Reauth Wait 

a) If the Auth Invalid event is associated with a particular TEK FSM, generate a TEK FSM 
Authorization Pending event for the TEK state machine responsible for the Auth Invalid event (i.e., 
the TEK FSM that either generated the event, or sent the Key Request message the BS responded to 
with an Auth Invalid message) 

8- C Authorized (Reauth) -> Reauth Wait 

a) Clear Authorization Grace timer 

b) Send Auth Request message to BS 

c) Set Auth Request retry timer to Reauth Wait Timeout 

7.2.5 TEK state machine 

The TEK state machine consists of six states and nine events (including receipt of messages) that can trigger 
state transitions. Like the Authorization state machine, the TEK state machine is presented in both a state 
flow diagram (Figure 132) and a state transition matrix (Table 134). As was the case for the Authorization 
state machine, the state transition matrix shall be used as the definitive specification of protocol actions 
associated with each state transition. 
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Shaded states in Figure 132 (Operational, Rekey Wait, and Rekey Reauthorize Wait) have valid keying 
material and encrypted traffic can be passed. 

The Authorization state machine starts an independent TEK state machine for each of its authorized SAIDs. 

As mentioned in 7.2.2, the BS maintains two active TEKs per SAID. The BS includes in its Key Replies 
both of these TEKs, along with their remaining lifetimes. The BS encrypts downlink traffic with the older of 
its two TEKs and decrypts uplink traffic with either the older or newer TEK, depending upon which of the 
two keys the SS was using at the time. The SS encrypts uplink traffic with the newer of its two TEKs and 
decrypts downlink traffic with either the older or newer TEK, depending upon which of the two keys the BS 
was using at the time. See 7.4 for details on SS and BS key usage requirements. 

Through operation of a TEK state machine, the SS attempts to keep its copies of an SAID Is TEKs 
synchronized with those of its BS, A TEK state machine issues Key Requests to refresh copies of its SAID's 
keying material soon after the scheduled expiration time of the older of its two TEKs and before the 
expiration of its newer TEK. To accommodate for SS/BS clock skew and other system processing and 
transmission delays, the SS schedules its Key Requests a configurable number of seconds before the newer 
TEK's estimated expiration in the BS. With the receipt of the Key Reply, the SS shall always update its 
records with the TEK Parameters from both TEKs contained in the Key Reply message. Figure 132 
illustrates the SS's scheduling of its key refreshes in conjunction with its management of an SAs active 
TEKs. 
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Figure 132— TEK state machine flow diagram 
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Table 134— TEK FSM state transition matrix 




7.2.5.1 States 

Start: This is the initial state of the FSM. No resources are assigned to or used by the FSM in this state— e.g., 
all timers are off, and no processing is scheduled. 

Operational Wait (Op Wait): The TEK state machine has sent its initial request (Key Request) for its SAID's 
keying material (TEK and CBC initialization vector), and is waiting for a reply from the BS. 

Operational Reauthorize Wait (Op Reauth Wait): The wait state the TEK state machine is placed in if it does 
not have valid keying material while the Authorization state machine is in the middle of a reauthorization 
cycle. 

Operational: The SS has valid keying material for the associated SAID. 

Rekey Wait: The TEK Refresh Timer has expired and the SS has requested a key update for this SAID. Note 
that the newer of its two TEKs has not expired and can still be used for both encrypting and decrypting data 
traffic. 

Rekey Reauthorize Wait (Rekey Reauth Wait): The wait state the TEK state machine is placed in if the TEK 
state machine has valid traffic keying material, has an outstanding request for the latest keying material, and 
the Authorization state machine initiates a reauthorization cycle. 
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7.2.5.2 Messages 

Note that the message formats are defined in detail in 6.3.2.3.9. 

Key Request: Request a TEK for this SAID. Sent by the SS to the BS and authenticated with keyed message 
digest. The message authentication key is derived from the AK. 

Key Reply: Response from the BS carrying the two active sets of traffic keying material for this SAID. Sent 
by the BS to the SS, it includes the SAID's TEKs, encrypted with a KEK derived from the AK. The Key 
Reply message is authenticated with a keyed message digest; the authentication key is derived from the AK. 

Key Reject: Response from the BS to the SS to indicate this SAID is no longer valid and no key will be sent. 
The Key Reject message is authenticated with a keyed message digest; the authentication key is derived 
from the AK. 

TEK Invalid: The BS sends an SS this message if it determines that the SS encrypted an uplink PDU with an 
invalid TEK, i.e., an SAID's TEK key sequence number, contained within the received PDU's MAC Header, 
is out of the BS's range of known, valid sequence numbers for that SAID. 

7.2.5.3 Events 

Stop: Sent by the Authorization FSM to an active (non-START state) TEK FSM to terminate TEK FSM and 
remove the corresponding SAID's keying material from the SS's key table. See Figure 131. 

Authorized: Sent by the Authorization FSM to a nonactive (START state) TEK FSM to notify TEK FSM of 
successful authorization. See Figure 131. 

Authorization Pending (Auth Fend): Sent by the Authorization FSM to TEK FSM to place TEK FSM in a 
wait state while Authorization FSM completes re-authorization. See Figure 131. 

Authorization Complete (Auth Comp): Sent by the Authorization FSM to a TEK FSM in the Operational 
Reauthorize Wait or Rekey Reauthorize Wait states to clear the wait state begun by the prior Authorization 
Pending event. See Figure 131. 

TEK Invalid: This event is triggered by either an SS's data packet decryption logic or by the receipt of a 
TEK Invalid message from the BS. 

An SS's data packet decryption logic triggers a TEK Invalid event if it recognizes a loss of TEK key 
synchronization between itself and the encrypting BS. For example, an SAID's TEK key sequence number, 
contained within the received downlink MAC PDU Header, is out of the SS's range of known sequence 
numbers for that SAID. 

A BS sends an SS a TEK Invalid message, triggering a TEK Invalid event within the SS, if the BS's 
decryption logic recognizes a loss of TEK key synchronization between itself and the SS. 

Timeout: A retry timer timeout. Generally, the particular request is retransmitted. 

TEK Refresh Timeout: The TEK refresh timer timed out. This timer event signals the TEK state machine to 
issue a new Key Request in order to refresh its keying material. The refresh timer is set to fire a configurable 
duration of time {TEK Grace Time) before the expiration of the newer TEK the SS currently holds. This is 
configured via the BS to occur after the scheduled expiration of the older of the two TEKs. 



Copyright © 2004 IEEE. All rights reserved. 



285 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



7.2.5.4 Parameters 

All configuration parameter values take the default values from Table 343 or may be specified in Auth Reply 
message. 

Operational Wait Timeout: Timeout period between sending of Key Request messages from the Op Wait 
state (see 11.9.19.4). 

Rekey Wait Timeout: Timeout period between sending of Key Request messages from the Rekey Wait state 
(see 11.9.19.5). 

TEK Grace Time: Time interval, in seconds, before the estimated expiration of a TEK that the SS starts 
rekeying for a new TEK. TEK Grace Time takes the default value from Table 343 or may be specified in a 
configuration setting within the Auth Reply message and is the same across all SAIDs (see 11.9.19.6). 

7.2.5.5 Actions 

Actions taken in association with state transitions are listed by <event> (<rcvd message>) <state>: 
1 -B Op Wait (Stop) -> Start 

a) Clear Key Request retry timer 

b) Terminate TEK FSM 

1 -C Op Reauth Wait (Stop) H> Start 

a) Terminate TEK FSM 
1-D Operational (Stop) -> Start 

a) Clear TEK refresh timer, which is timer set to go off "TEK Grace Time" seconds prior to the TEK's 
scheduled expiration time 

b) Terminate TEK FSM 

c) Remove SAID keying material from key table 
1-E Rekey Wait (Stop) Start 

a) Clear Key Request retry timer 

b) Terminate TEK FSM 

c) Remove SAID keying material from key table 

1- F Rekey Reauth Wait (Stop) -» Start 

a) Terminate TEK FSM 

b) Remove SAID keying material from key table 

2- A Start (Authorized) -> Op Wait 

a) Send Key Request message to BS 

b) Set Key Request retry timer to Operational Wait Timeout 
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3-B Op Wait (Auth Pend) -> Op Reauth Wait 

a) Clear Key Request retry timer 

3- E Rekey Wait {Auth Pend) -> Rekey Reauth Wait 
a) Clear Key Request retry timer 

4- C Op Reauth Wait (Auth Comp) -> Op Wait 

a) Send Key Request message to BS 

b) Set Key Request retry timer to Operational Wait Timeout 

4- F Rekey Reauth Wait (Auth Comp) -> Rekey Wait 

a) Send Key Request message to BS 

b) Set Key Request retry timer to Rekey Wait Timeout 

5- D Operational (TEK Invalid) -> Op Wait 

a) Clear TEK refresh timer 

b) Send Key Request message to BS 

c) Set Key Request retry timer to Operational Wait Timeout 

d) Remove SAID keying material from key table 

5-E Rekey Wait (TEK Invalid) -> Op Wait 

a) Clear TEK refresh timer 

b) Send Key Request message to BS 

c) Set Key Request retry timer to Operational Wait Timeout 

d) Remove SAID keying material from key table 

5- F Rekey Reauth Wait (TEK Invalid) -» Op Reauth Wait 
a) Remove SAID keying material from key table 

6- B Op Wait (Timeout) Op Wait 

a) Send Key Request message to BS 

b) Set Key Request retry timer to Operational Wait Timeout 

6- E Rekey Wait (Timeout) -> Rekey Wait 

a) Send Key Request message to BS 

b) Set Key Request retry timer to Rekey Wait Timeout 

7- D Operational (TEK Refresh Timeout) -> Rekey Wait 

a) Send Key Request message to BS 

b) Set Key Request retry timer to Rekey Wait Timeout 
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8-B Op Wait (Key Reply) Operational 

a) Clear Key Request retry timer 

b) Process contents of Key Reply message and incorporate new keying material into key database 

c) Set the TEK refresh timer to go off "TEK Grace Time" seconds prior to the key's scheduled 
expiration 

8- E Rekey Wait (Key Reply) Operational 

a) Clear Key Request retry timer 

b) Process contents of Key Reply message and incorporate new keying material into key database 

c) Set the TEK refresh timer to go off "TEK Grace Time" seconds prior to the key's scheduled 
expiration 

9- B Op Wait (Key Reject) Start 

a) Clear Key Request retry timer 

b) Terminate TEK FSM 

9-E Rekey Wait (Key Reject) -> Start 

a) Clear Key Request retry timer 

b) Terminate TEK FSM 

c) Remove SAID keying material from key table 
7.3 Dynamic SA creation and mapping 

Dynamic Security Associations are SAs that a BS establishes and eliminates dynamically in response to the 
enabling or disabling of specific downlink service flows. SSs learn the mapping of a particular 
privacy-enabled service flow to that flow's dynamically assigned SA through the exchange of DSx 
messages. 

7.3.1 Dynamic SA creation 

The BS may dynamically establish SAs by issuing an SA Add message. Upon receiving an SA Add 
message, the SS shall start a TEK state machine for each SA listed in the message. 

7.3.2 Dynamic mapping of SA 

When creating a new service flow, an SS may request an existing S A be used by passing the SAID of the SA 
in a DSA-REQ or DSC-REQ message. The BS checks the SS's authorization for the requested SA and 
generates appropriate response using a DSA-RSP or DSC-RSP message correspondingly. 

With BS-initiated dynamic service creations, a BS may also map a new service flow to an existing SA that is 
supported by a specific SS. The SAID of the SA shall be communicated to the SS in a DSA-REQ or 
DSC-REQ message. 
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7.4 Key usage 
7.4.1 BS key usage 

The BS is responsible for maintaining keying information for all SAs. The PKM protocol defined in this 
specification describes a mechanism for synchronizing this keying information between a BS and its client 
SS. 

7.4.1.1 AK key lifetime 

After an SS completes basic capabilities negotiation, it shall initiate an authorization exchange with its BS. 
The BS's first receipt of an Auth Request message from the unauthorized SS shall initiate the activation of a 
new AK, which the BS sends back to the requesting SS in an Auth Reply message. This AK shall remain 
active until it expires according to its predefined AK Lifetime, a BS system configuration parameter. 

The AK's active lifetime a BS reports in an Authorization Reply message shall reflect, as accurately as an 
implementation permits, the remaining lifetimes of AK at the time the Authorization Reply message is sent. 

If an SS fails to reauthorize before the expiration of its current AK, the BS shall hold no active AKs for the 
SS and shall consider the SS unauthorized. A BS shall remove from its keying tables all TEKs associated 
with an unauthorized SS's Primary SA. 

7.4.1 .2 AK transition period on BS side 

The BS shall always be prepared to send an AK to an SS upon request. The BS shall be able to support two 
simultaneously active AKs for each client SS. The BS has two active AKs during an AK transition period; 
the two active keys have overlapping lifetimes. 

An AK transition period begins when the BS receives an Auth Request message from an SS and the BS has 
a single active AK for that SS. In response to this Auth Request, the BS activates a second AK [see point (a) 
and (d) in Figure 133], which shall have a key sequence number one greater (modulo 16) than that of the 
existing AK and shall be sent back to the requesting SS in an Auth Reply message. The BS shall set the 
active lifetime of this second AK to be the remaining lifetime of the first AK [between points (a) and (c) in 
Figure 133], plus the predefined AK Lifetime; thus, the second, "newer" key shall remain active for one AK 
Lifetime beyond the expiration of the first, "older" key. The key transition period shall end with the 
expiration of the older key. This is depicted on the right-hand side of Figure 133. 

As long as the BS is in the midst of an SS's AK transition period, and thus is holding two active AKs for that 
SS, it shall respond to Auth Request messages with the newer of the two active keys. Once the older key 
expires, an Auth Request shall trigger the activation of a new AK, and the start of a new key transition 
period. 
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Figure 133— AK management in BS and SS 
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7.4.1.3 BS usage of AK 

The BS shall use keying material derived from the SS's AK for the following: 

a) Verifying the HMAC-Digests in Key Request messages received from that SS, 

b) Calculating the HMAC-Digests it writes into Key Reply, Key Reject, and TEK Invalid messages 
sent to that SS, and 

c) Encrypting the TEK in the Key Reply messages it sends to that SS. 

A BS shall use an HMACJCEY_U (see 7.5.4.3) derived from one of the SS's active AKs to verify the 
HMAC-Digest in Key Request messages received from the SS. The AK Key Sequence Number 
accompanying each Key Request message allows the BS to determine which HMAC_KEY_U was used to 
authenticate the message. If the AK Key Sequence Number indicates the newer of the two AKs, the BS shall 
identify this as an implicit acknowledgment that the SS has obtained the newer of the SS's two active AKs 
[see points (b) in Figure 133]. 

A BS shall use an HMAC_KEY_D derived from the active AK selected above (see also 7.5.4.3) when 
calculating HMAC-Digests in Key Reply, Key Reject, and TEK Invalid message. When sending Key Reply, 
Key Reject, or TEK Invalid messages within a key transition period (i.e., when two active AKs are 
available), if the newer key has been implicitly acknowledged, the BS shall use the newer of the two active 
AKs. If the newer key has not been implicitly acknowledged, the BS shall use the older of the two active 
AKs to derive the KEK and the HMAC_KEY_D. 

The BS shall use a KEK derived from an active AK when encrypting the TEK in the Key Reply messages. 
The right-hand side of Figure 133 illustrates the BS's policy regarding its use of AKs, where the shaded 
portion of an AK's lifetime indicates the time period during which that AK shall be used to derive the 
HMAC_KEY_U, HMAC_KEY__D, and KEK. 

For calculating the HMAC-Digest in the HMAC Tuple attribute, the BS shall use the HMAC_KEY_U and 
HMAC_KEY_D derived from one of the active AKs. For signing messages, if the newer AK has been 
implicitly acknowledged, the BS shall use the newer of the two active AKs to derive the HMAC_KEY_D. If 
the newer key has not been implicitly acknowledged, the BS shall use the older of the two active AKs to 
derive the HM AC_KE Y_D . The HMAC Key Sequence Number in the HMAC Tuple, equal to the AK's 
sequence number from which the HMAC_KEY_D was derived, enables the SS to correctly determine which 
HMAC_KEY_D was used for message authentication. 

When receiving messages containing the HMAC Tuple attribute, the BS shall use the HMAC_KEY_U 
indicated by the HMAC Key Sequence Number to authenticate the messages. 

7.4.1.4 TEK lifetime 

The BS shall maintain two sets of active TEKs (and their associated Initialization Vectors, or IVs) per SAID, 
corresponding to two successive generations of keying material. The two generations of TEKs shall have 
overlapping lifetimes determined by TEK Lifetime, a predefined BS system configuration parameter. The 
newer TEK shall have a key sequence number one greater (modulo 4) than that of the older TEK. Each TEK 
becomes active halfway through the lifetime of its predecessor and expires halfway through the lifetime of 
its successor. Once a TEK's lifetime expires, the TEK becomes inactive and shall no longer be used. 

The Key Reply messages sent by a BS contain TEK parameters for the two active TEKs. The TEKs' active 
lifetimes a BS reports in a Key Reply message shall reflect, as accurately as an implementation permits, the 
remaining lifetimes of these TEKs at the time the Key Reply message is sent. 
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7.4.1.5 BS usage of TEK 

The BS transitions between the two active TEKs differently, depending on whether the TEK is used for 
downlink or uplink traffic. For each of its SAIDs, the BS shall transition between active TEKs according to 
the following rules: 

a) At expiration of the older TEK, the BS shall immediately transition to using the newer TEK for 
encryption. 

b) The uplink transition period begins from the time the BS sends the newer TEK in a Key Reply 
message and concludes once the older TEK expires. 

It is the responsibility of the SS to update its keys in a timely fashion; the BS shall transition to a new 
downlink encryption key regardless of whether a client SS has retrieved a copy of that TEK. 

The BS uses the two active TEKs differently, depending on whether the TEK is used for downlink or uplink 
traffic. For each of its SAIDs, the BS shall use the two active TEKs according to the following rules: 

a) The BS shall use the older of the two active TEKs for encrypting downlink traffic. 

b) The BS shall be able to decrypt uplink traffic using either the older or newer TEK. 

Note that the BS encrypts with a given TEK for only the second half of that TEK's total lifetime. The BS is 
able, however, to decrypt with a TEK for the TEK's entire lifetime. 

The right-hand side of Figure 134 illustrates the BS's management of an SA's TEKs, where the shaded 
portion of a TEK's lifetime indicates the time period during which that TEK shall be used to encrypt MAC 
PDU payloads. 

7.4.1.6 Node re-authorization in Mesh Mode during normal operation 

When re-authorizing "with the network, the re-authorizing node shall tunnel the authorization messages as 
shown in Figure 131 over UDP. 

7.4.2 SS key usage 

The SS is responsible for sustaining authorization with its BS and maintaining an active AK. An SS shall be 
prepared to use its two most recently obtained AKs according to the following manner. 

7.4.2.1 SS reauthorization 

AKs have a limited lifetime and shall be periodically refreshed. An SS refreshes its AK by reissuing an Auth 
Request to the BS. The Authorization State Machine (7.2.4) manages the scheduling of Auth Requests for 
refreshing AKs. 

An SS's Authorization state machine schedules the beginning of reauthorization a configurable duration of 
time, the Authorization Grace Time, [see points (x) and (y) in Figure 133], before the SS's latest AK is 
scheduled to expire. The Authorization Grace Time is configured to provide an SS with an authorization 
retry period that is sufficiently long to allow for system delays and provide adequate time for the SS to 
successfully complete an Authorization exchange before the expiration of its most current AK. 

Note that the BS does not require knowledge of the Authorization Grace Time. The BS, however, shall track 
the lifetimes of its AKs and shall deactivate a key once it has expired. 
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Figure 134 — TEK management in BS and SS 
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7.4.2.2 SS usage of AK 

An SS shall use the HMAC_KEY_U derived from the newer of its two most recent AKs when calculating 
the HMAC-Digests it attaches to Key Request messages. 

The SS shall be able to use the HMAC_KEY_D derived from either of its two most recent AKs to 
authenticate Key Reply, Key Reject, and TEK Reject messages. The SS shall be able to decrypt an encrypted 
TEK in a Key Reply message with the KEK derived from either of its two most recent AKs. The SS shall 
use the accompanying AK Key Sequence Number to determine which set of keying material to use. 

The left-hand side of Figure 133 illustrates an SS's maintenance and usage of its AKs, where the shaded 
portion of an AK's lifetime indicates the time period during which that AK shall be used to decrypt TEKs. 
Even though it is not part of the message exchange, Figure 133 also shows the implicit acknowledgment of 
the reception of a new AK via the transmission of a Key Request message using the key sequence of the new 
AK. 

An SS shall use the HMAC_KEY_U derived from the newer of its two most recent AKs when calculating 
the HMAC-Digests of the HM AC Tuple attribute. 

7.4.2.3 SS usage of TEK 

An SS shall be capable of maintaining two successive sets of traffic keying material per authorized SAID. 
Through operation of its TEK state machines, an SS shall request a new set of traffic keying material a 
configurable amount of time, the TEK Grace Time [see points (x) and (y) in Figure 134], before the SS's 
latest TEK is scheduled to expire. 

For each of its authorized SAIDs, the SS 

a) Shall use the newer of its two TEKs to encrypt uplink traffic, and 

b) Shall be able to decrypt downlink traffic encrypted with either of the TEKs. 

The left-hand side of Figure 134 illustrates the SS's maintenance and usage of an SA's TEKs, where the 
shaded portion of a TEK's lifetime indicates the time period during which that TEK shall be used to encrypt 
MAC PDU payloads. 

7.4.2.4 TEK usage in Mesh Mode 

For each of its SAIDs, the Neighbor shall transition between active TEKs according to the following rules: 

a) At expiration of the older TEK, the Neighbor shall immediately transition to using the newer TEK 
for encryption. 

b) The Neighbor that generated the TEK shall use the older of the two active TEKs for encrypting 
traffic towards the Node that initiated the TEK exchange. 

c) The Neighbor that generated the TEK shall be able to decrypt traffic from each Node using either 
the older or newer TEK. 

For each of its authorized SAIDs, the initiator Node 

a) Shall use the newer of its two TEKs to encrypt traffic towards its Neighbors with which it initiated a 
TEK exchange, and 

b) Shall be able to decrypt traffic from the Neighbor encrypted with either of the TEKs. 
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7.4.2.5 Node usage of the Operator Shared Secret in Mesh Nodes 

Each node shall be capable of maintaining two active Operator Shared Secrets. A Node shall use the 
Operator Shared Secret to calculate a HMAC-Digest for the Key Request and Key Reply messages when 
exchanging TEKs with its neighboring nodes. 

7.5 Cryptographic methods 

This subclause specifies the cryptographic algorithms and key sizes used by the PKM protocol. All SS and 
BS implementations shall support the method of packet data encryption defined in 7.5.1.1, encryption of the 
TEK as specified in 7.5.2, and message digest calculation as specified in 7.5.3. 

7.5.1 Data Encryption methods 

7.5.1.1 Data encryption with DES in CBC mode 

If the data encryption algorithm identifier in the cryptographic suite of an S A equals 0x01, data on 
connections associated with that SA shall use the CBC mode of the US Data Encryption Standard (DES) 
algorithm (HPS 46-3, FIPS 74, FIPS 8 1 ) to encrypt the MAC PDU payloads. 

The CBC IV shall be calculated as follows: in the downlink, the CBC shall be initialized with the 
exclusive-or (XOR) of (1) the IV parameter included in the TEK keying information, and (2) the content of 
the PHY Synchronization field (right justified) of the latest DL-MAR In the uplink, the CBC shall be 
initialized with the XOR of (1) the IV parameter included in the TEK keying information, and (2) the 
content of the PHY Synchronization field of the DL-MAP that is in effect when the UL-MAP for the uplink 
transmission is created/received. 

Residual termination block processing shall be used to encrypt the final block of plaintext when the final 
block is less than 64 bits. Given a final block having n bits, where n is less than 64, the next-tq-last cipher- 
text block shall be DES encrypted a second time, using the electronic code book (ECB) mode, and the most 
significant n bits of the result are XORed with the final n bits of the payload to generate the short final cipher 
block. In order for the receiver to decrypt the short final cipher block, the receiver DES encrypts the 
next-to-last ciphertext block, using the ECB mode, and XORs the most significant n bits with the short final 
cipher block in order to recover the short final cleartext block. This encryption procedure is depicted in 
Figure 9.4 of Schneier [B42]. 

In the special case when the payload portion of the MAC PDU is less than 64 bits, the IV shall be DES 
encrypted and the most significant n bits of the resulting ciphertext, corresponding to the number of bits of 
the payload, shall be XORed with the n bits of the payload to generate the short cipher block. 15 

7.5.1.2 Data encryption with AES in CCM mode 

If the data encryption algorithm identifier in the cryptographic suite of an SA equals 0x02, data on 
connections associated with that SA shall use the CCM mode of the US Advanced Encryption Standard 
(AES) algorithm (NIST Special Publication 800-38C, FTPS- 197) to encrypt the MAC PDU payloads. 



If two or more PDUs with less than 8 byte payloads are transmitted in the same frame using the same SA, the XOR of the payload 
plaintexts can be found easily. In practice, this situation is very unlikely to occur, as payloads are typically larger than 8 bytes. In the 
case that multiple payloads of less than 8 bytes are to be transmitted in the same frame on the same S A and service, packing of the short 
SDUs into a single PDU will eliminate this weakness. If the SDUs are for different services, packing the SDUs with zero-length 
fictitious SDUs allows the use of the Packing subheader to extend the size of the PDU to at least 8 bytes. 
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7.5.1.2.1 PDU Payload Format 

The PDU payload shall be prepended with a 4-byte PN (Packet Number). The PN shall be transmitted in 
little endian byte order. The PN shall not be encrypted. 

The plaintext PDU shall be encrypted and authenticated using the active TEK, according to the CCM 
specification. This includes appending an 8-byte ICV (Integrity Check Value) to the end of the payload and 
encrypting both the plaintext payload and the appended ICV. 

The ciphertext ICV is transmitted in little endian byte order. 

The processing yields a payload that is 12 bytes longer than the plaintext payload. 



Payload before encryption 
L Bytes 



Plaintext payload 



Payload after encryption 
L+ 12 Bytes 



4 Bytes 



8 Bytes 
► 



PN 



Ciphertext Payload 



Ciphertext ICV 



Figure 135— TEK management in BS and SS 



7.5.1.2.2 PN (Packet Number) 

The PN associated with an SA shall be set to 1 when the SA is established and when a new TEK is installed. 
The PN shall be transmitted in little endian order in the MAC PDU as described in 7.5.1.2.1. After each 
PDU transmission, the PN shall be incremented by 1. On uplink connections, the PN shall be XORed with 
0x80000000 prior to encryption and transmission. On downlink connections, the PN shall be used without 
' such modification. 16 

Any tuple value of {PN, KEY} shall not be used more than once for the purposes of transmitting data. 17 The 
SS shall ensure that a new TEK is requested and transferred before the PN on either the SS or BS reaches 
0x7FFFFFFF. If the PN in either the SS or BS reaches 0x7FFFFFFF without new keys being installed, 
transport communications on that SA shall be halted until new TEKs are installed. 

7.5.1 .2.3 CCM Algorithm 

The NIST CCM specification defines a number of algorithm parameters. These parameters shall be fixed to 
specific values when used in SAs with a data encryption algorithm identifier of 0x02. 



16 This achieves the splitting of the PN space. 0x00000001 - 0x7FFFFFFF for the downlink and 0x80000001 - OxFFFFFFFF on the 
uplink, preventing a PN collision between the uplink and downlink 

17 Sending two packets encoded with the same key and PN will eliminate all security guarantees of CCM mode. 
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The number of octets in the authentication field M shall be set to 8. Consistent with the CCM specification 
the 3 bit binary encoding of M shall be 01 1 . 

The size of the length field shall be set to 2. Consistent with the CCM specification, the 3-bit binary encod- 
ing of the DLEN size field shall be 001. 

The length of the additional authenticated data string 1(a) shall be set to 0. 

The nonce shall be 13 bytes long. Bytes 1 through 5 shall be set to the first five byte of the GMH (thus 
excluding the HCS). Bytes 6 through 9 are reserved and shall be set to 0x00000000. Bytes 10 through 13 
shall be set to the value of the PN. Byte 10 shall take the least significant byte and byte 13 shall take the most 
significant byte. 

Consistent with the CCM specification, the initial block B 0 is formatted as shown in Figure 136. 
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Figure 136— Initial CCM Block B 0 

Note the big endian ordering of the DLEN value is opposite that of the normal little endian representation. 
This is to remain compliant with the letter of the NIST CCM specification. 

The sixth byte of the GMH is not included in the nonce since it is redundant. 
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Consistent with the NIST CCM specification the counter blocks A { are formatted as shown in Figure 137. 
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Figure 137— Construction of Aj 
7.5.1.2.4 Receive Processing Rules 



On receipt of a PDU the receiving SS or BS shall decrypt and authenticate the PDU consistent with the NIST 
CCM specification configured as specified in 7.5.1.2.3. 

Packets that are found to be not authentic shall be discarded. 

Receiving BS or SSs shall maintain a record of the highest value PN receive for each SA. If a packet is 
received with a PN that is equal to or less than the recorded maximum for the SA is protected under, then the 
packet shall be discarded as a replay attempt. 

7.5.2 Encryption of TEK 



The following options listed in 7.5.2.1 through 7.5.2.3 may be used. 
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7.5.2.1 Encryption of TEK with 3-DES 

This method of encrypting the TEK shall be used for SAs with the TEK encryption algorithm identifier in 
the cryptographic suite equal to 0x01. 

The BS encrypts the value fields of the TEK in the Key Reply messages it sends to client SS. This field is 
encrypted using two-key 3-DES in the EDE mode (Schneier [B42]): 

encryption: C = Ekl[Dk2[Ekl[P]]] 
decryption: P = Dkl[Ek2[Dkl[C]]] 
P = Plaintext 64-bit TEK 
C = Ciphertext 64-bit TEK 
kl = leftmost 64 bits of the 128-bit KEK 
k2 = rightmost 64 bits of the 128-bit KEK 
E[ ] = 56-bit DES ECB mode encryption 
D[ ] = 56-bit DES ECB decryption 

Subclause 7.5.4 describes how the KEK is derived from the AK. 

7.5.2.2 Encryption of TEK with RSA 

The RSA method of encrypting the TEK (PKCS #1 v2.0) shall be used for SAs with the TEK encryption 
algorithm identifier in the cryptographic suite equal to 0x02. 

7.5.2.3 Encryption of TEK-128 with AES 

This method of encrypting the TEK-128 shall be used for SAs with the TEK encryption algorithm identifier 
in the cryptographic suite equal to 0x03. 

The BS encrypts the value fields of the TEK-128 in the Key Reply messages it sends to client SS. This field 
is encrypted using 128-bit AES in ECB mode. 

encryption: C = Ekl[P] 

decryption: P = Dkl[C] 

P = Plaintext 128-bit TEK 

C = Ciphertext 128-bit TEK 

kl = the 128-bit KEK 

E[ ] = 128-bit AES ECB mode encryption 

D[ ] = 128-bit AES ECB decryption 

Subclause 7.5.4 describes how the KEK is derived from the AK. 

7.5.3 Calculation of HMAC-Digests 

The calculation of the keyed hash in the HMAC-Digest attribute and the HMAC Tuple shall use the HMAC 
(IETF RFC 2104) with the secure hash algorithm SHA-1 (FTPS 180-1). The downlink authentication key 
HMAC_KEYJD shall be used for authenticating messages in the downlink direction. The uplink 
authentication key HMAC_KEY_U shall be used for authenticating messages in the uplink direction. 
Uplink and downlink message authentication keys are derived from the AK (see 7.5.4 for details). The 
HMAC Sequence number in the HMAC Tuple shall be equal to the AK Sequence Number of the AK from 
which the HMAC_KEY_x was derived. 
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In Mesh Mode HMAC-Digests calculated with the key HMAC_KEY_S shall be supported. When 
calculating the digest with this key the HMAC sequence Number in the HMAC tuple shall be equal to the 
Operator Shared Secret Sequence Number. 

The digest shall be calculated over the entire MAC Management message with the exception of the 
HMAC-Digest and HMAC Tuple attributes. 

7.5.4 Derivation of TEKs, KEKs, and message authentication keys 

The BS generates AKs, TEKs, and IVs. A random or pseudo-random number generator shall be used to 
generate AKs and TEKs. A random or pseudo-random number generator may also be used to generate IVs. 
Regardless of how they are generated, IVs shall be unpredictable. Recommended practices for generating 
random numbers for use within cryptographic systems are provided in IETF RFC 1750 [B30]. 

7.5.4.1 DES Keys 

FIPS 81 defines 56-bit DES keys as 8-byte (64-bit) quantities where the seven most significant bits (i.e., 
seven leftmost bits) of each byte are the independent bits of a DES key, and the least significant bit (i.e., 
rightmost bit) of each byte is a parity bit computed on the preceding seven independent bits and adjusted so 
that the byte has odd parity. 

PKM does not require odd parity. The PKM protocol generates and distributes 8-byte DES keys of arbitrary 
parity, and it requires that implementations ignore the value of the least significant bit of each. 

7.5.4.2 3-DES KEKs 

The keying material for two-key 3-DES consists of two distinct (single) DES keys. 

The 3-DES KEK used to encrypt the TEK is derived from a common AK. The KEK shall be derived as 
follows: 

KEK = Truncate(SHA(K_PADJCEK | AK),128) 
KJADJCEK = 0x53 repeated 64 times, i.e., a 512-bit string. 

Truncate(jc,n) denotes the result of truncating x to its leftmost n bits. 

SHA(jc| y) denotes the result of applying the SHA-1 function to the concatenated bit strings x and y. 

The keying material of 3-DES consists of two distinct DES keys. The 64 most significant bits of the KEK 
shall be used in the encrypt operation. The 64 least significant bits shall be used in the decrypt operation. 

7.5.4.3 HMAC authentication keys 

The HMAC authentication keys are derived as follows: 

HMAC_KEY_D = SHA(H_PAD_D|AK) 
HMAC_KEY_U = SHA(H_PAD_U|AK) 
HMAC_KEY_S = SHA(H_PAD_D|Operator Shared Secret) 

with 

H _PAD_D = 0x3 A repeated 64 times 
H_PAD_U = 0x5C repeated 64 times 
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7.5.5 Public-key encryption of AK 

AKs in Auth Reply messages shall be RSA public-key encrypted, using the SS's public key. The protocol 
uses 65537 (0x010001) as its public exponent and a modulus length of 1024 bits. The PKM protocol 
employs the RSAES-OAEP encryption scheme (PKCS #1). RSAES-OAEP requires the selection of a hash 
function, a mask-generation function, and an encoding parameter string. The default selections specified in 
PKCS #1 shall be used when encrypting the AK. These default selections are SHA-1 for the hash function, 
MGF1 with SHA-1 for the mask-generation function, and the empty string for the encoding parameter 
string. 

7.5.6 Digital signatures 

The Protocol employs the RSA Signature Algorithm (PKCS #1) with SHA-1 (FIPS 186-2) for both of its 
certificate types. 

As with its RSA encryption keys, Privacy uses 65537 (0x010001) as the public exponent for its signing 
operation. Manufacturer CAs shall employ signature key modulus lengths of at least 1024 bits and no 
greater than 2048 bits. 

7.6 Certificate profile 
7.6.1 Certificate format 

This subclause describes the X.509 (IETF RFC 2459) Version 3 certificate format and certificate extensions 
used in IEEE 802.16-compliant SSs. Table 135 summarizes the basic fields of an X.509 Version 3 
certificate. 



Table 135 — Basic fields of an X.509 Version 3 certificate 



X.509 v3 field 


Description 


tbsCertificate. version 


Indicates the X.509 certificate version. Always set to v3 (value of 2). 


tbsCertificate.serialNumber 


Unique integer the issuing CA assigns to the certificate. 


tbsCertificate.signature 


Object identifier (OID) and optional parameters defining algorithm used to 
sign die certificate. This field shall contain the same algorithm identifier as 
the signatureAlgorithm field. 


tbsCertificate.issuer 


Distinguished Name of the CA that issued the certificate. 


tbsCertificate.validity 


Specifies when the certificate becomes active and when it expires. 


tbsCertificate. subject 


Distinguished Name identifying the entity whose public key is certified in 
the subjectpublic key information field. 


tbsCertificate.subjectPublicKeylnfo 


Field contains the public key material (public key and parameters) and the 
identifier of the algorithm with which the key is used. 


tbsCertificate.issuerUniquelD 


Optional field to allow reuse of issuer names over time. 


tbsCertificate.subjectUnique ID 


Optional field to allow reuse of subject names over time. 


tbsCertificate.extensions 


The extension data. 
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Table 135— Basic fields of an X.509 Version 3 certificate (continued) 



X.509 v3 field 


Description 


signatureAlgorithm 


OID and optional parameters defining algorithm used to sign the certificate. 
This field shall contain the same algorithm identifier as the signature field 
in tbsCertificate. 


signatureValue 


Digital signature computed upon the ASN.l DER encoded tbsCertificate. 



All certificates described in this specification shall be signed with the RSA signature algorithm using 
SHA-1 as the one-way hash function. The RSA signature algorithm is described in PKCS #1; SHA-1 is 
described in FIPS 180-1. Restrictions posed on the certificate values are described in the following 
subclauses: 

7.6.1.1 tbsCertif icate.validity.notBef ore and tbsCertificate.validity.notAfter 

SS certificates shall not be renewable and shall thus have a validity period greater than the operational 
lifetime of the SS. A Manufacturer CA certificate's validity period should exceed that of the SS certificates 
it issues. The validity period of an SS certificate shall begin with the date of generation of the device's 
certificate; the validity period should extend out to at least 10 years after that manufacturing date. Validity 
periods shall be encoded as UTCTime. UTCTime values shall be expressed Greenwich Mean Time (Zulu) 
and shall include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is 
zero. 

7.6.1 .2 tbsCertif icate.serialNumber 

Serial numbers for SS certificates signed by a particular issuer shall be assigned by the manufacturer in 
increasing order. Thus, if the tbsCertificate. validity. notBef ore field of one certificate is greater than the 
tbsCertificate. validity. notBef ore field of another certificate, then the serial number of the first certificate 
shall be greater than the serial number of the second certificate. 

7.6.1 .3 tbsCertif icate.signature and signatureAlgorithm 

All certificates described in this specification shall be signed with the RSA signature algorithm, using 
SHA-1 as the one-way hash function. The RSA signature algorithm is described in PKCS #1; SHA-1 is 
described in FIPS 180-1. The ASN.l OID used to identify the "SHA-1 with RSA" signature algorithm is 

sha-lWithRSAEncryption OBJECT IDENTIFIER ::= 

{ iso(l) member-body(2) us(840) rsadsi(113549) pkcs(l) pkcs-l(l) 5} 

When the sha-lWithRSAEncryption OID appears within the ASN.l type Algorithmldentifier, as is the case 
with both tbsCertificate.signature and signatureAlgorithm, the parameters component of that type is the 
ASN.l type NULL. 

7.6.1.4 tbsCertif icate.issuer and tbsCertificate.subject 

X.509 Names are SEQUENCES of RelativeDistinguishedNames, which are in turn SETs of 
AttributeTypeAndValue. AttributeTypeAndValue is a SEQUENCE of an AttributeType (an OBJECT 
IDENTIFIER) and an AttributeValue. The value of the countryName attribute shall be a two-character 
PrintableString, chosen from ISO 3166; all other Attribute Values shall be encoded as either 
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T.61/TeletexString or PrintableString character strings. The PrintableString encoding shall be used if the 
character string contains only characters from the PrintableString set. Specifically: 

abcdefghijklmnopqrstuvwxyz 
ABCDEFGHIJKLMNOPQRSTUVWXYZ 
0123456789 
'()+-./:=? and space 

The T.61/TeletexString shall be used if the character string contains other characters. The following OIDs 
are needed for defining issuer and subject Names in PKM certificates: 

id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} 
id-at-commonName OBJECT IDENTIFIER ::= {id-at 3} 
id-at-countryName OBJECT IDENTIFIER ::= {id-at 6} 
id-at-localityName OBJECT IDENTIFIER ::= {id-at 7} 
id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8} 
id-at-organizationName OB JECT IDENTIFIER ::= {id-at 10} 
id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11} 

The following subclauses describe the attributes that comprise the subject Name forms for each type of 
PKM certificate. Note that the issuer name form is the same as the subject of the issuing certificate. 
Additional attribute values that are present but unspecified in the following forms should not cause a device 
to reject the certificate. 

7.6.1.4.1 Manufacturer certificate 

countryName=<Country of Manufacturer 

[stateOrProvinceName=<state/province>] 

[localityName=<City>] 

organizationName=<Company Name> 

organizationalUnitName=WirelessMAN 

[organizationalUnitName=<Manufacturing Location>] 

commonName=<Company Name> Certification Authority> 

The countryName, organizationName, and commonName attributes shall be included and shall have the 
values shown. The organizationalUnitName having the value "WirelessMAN" shall be included. The 
organizationalUnitName representing manufacturing location should be included. If included, it shall be 
preceded by the organizationalUnitName having value "WirelessMAN." The stateOrProvinceName and 
localityName may be included. Other attributes are not allowed and shall not be included. 

7.6.1.4.2 SS certificate 

countryName=<Country of Manufacturer 
organizationName=<Company Name> 
organizationalUnitName=<manufacturing location> 
commonName=<Serial Number> 
commonName=<MAC Address> 

The MAC address shall be the SS's MAC address. It is expressed as six pairs of hexadecimal digits 
separated by colons (:), e.g., "00:60:21 :A5:0A:23." The Alpha HEX characters (A-F) shall be expressed as 
uppercase letters. 

The organizationalUnitName in an SS certificate, which describes the modem's manufacturing location, 
should be the same as the organizationalUnitName in the issuer Name describing a manufacturing location. 
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The countryName, organizationName, organizationalUnitName, and commonName attributes shall be 
included. Other attributes are not allowed and shall not be included. 

7.6.1 .5 tbsCertif icate.subjectPublicKeylnfo 

The tbsCertificate.subjectPublicKeylnfo field contains the public key and the public key algorithm 
identifier. The tbsCertificate.subjectPublicKeylnfo.algorithm field is an Algorithmldentifier structure. The 
Algorithemldentifier's algorithm shall be RSA encryption, identified by the following OID: 

pkcs-1 OBJECT IDENTIFIER ::= { iso(l) member-body(2) us(840) 
rsadsi(113549) pkcs(l) 1} 

rsaEncryption OBJECT IDENTIFIER ::= { pkcs- 1 1 } 

The Algorithmldentifier's parameters field shall have ASN.l type NULL. The RSA public key shall be 
encoded using the ASN.l type RSAPublicKey: 

RSAPublicKey ::= SEQUENCE { 
modulus INTEGER, n 
publicExponent INTEGER, - e } 

where modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded 
RSAPublicKey is the value of the BIT STRING tbsCertif icate.subjectPublicKeylnfo.subjectPublic Key. 

7.6.1.6 tbsCertificate.issuerUniquelD and tbsCertif icate.subjectUniquelD 

The issuerUniquelD and subjectUniquelD fields shall be omitted for both of the PKM's certificate types. 

7.6.1 .7 tbsCertif icate.extensions 

7.6.1.7.1 SS certificates 

SS certificates may contain noncritical extensions; they shall not contain critical extensions. If the Key- 
Usage extension is present, the key Agreement and keyEncipherment bits shall be turned on, keyCertSign 
and cRLSign bits shall be turned off, and all other bits should be turned off. 

7.6.1.7.2 Manufacturer certificates 

Manufacturer certificates may contain the Basic Constraints extension. If included, the Basic Constraints 
extension may appear as a critical extension or as a noncritical extension. Manufacturer certificates may 
contain noncritical extensions; they shall not contain critical extensions other than, possibly, the Basic 
Constraints extension. If the KeyUsage extension is present in a Manufacturer certificate, the keyCertSign 
bit shall be turned on and all other bits should be turned off. 

7.6.1.8 signature Value 

In all three PKM certificate types, the signature Value contains the RSA (with SHA-1) signature computed 
over the ASN.l DER encoded tbsCertif icate. The ASN.l DER encoded tbsCertificate is used as input to the 
RSA signature function. The resulting signature value is ASN.l encoded as a bit string and included in the 
Certificate's signature Value field. 

7.6.2 SS certificate storage and management in the SS 

Manufacturer-issued SS certificates shall be stored in SS permanent, write-once memory. SSs that have 
factory-installed RSA private/public key pairs shall also have factory-installed SS certificates. SSs that rely 
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on internal algorithms to generate an RSA key pair shall support a mechanism for installing a manufacturer- 
issued SS certificate following key generation. The CA certificate of the Manufacturer CA that signed the 
SS certificate shall be embedded into the SS software. If a manufacturer issues SS certificates with multiple 
Manufacturer CA certificates, the SS software shall include ALL of that manufacturer's CA certificates. The 
specific Manufacturer CA certificate installed by the SS [i.e., advertised in Authentication Information 
messages and returned by the management information base (MIB) object] shall be that identifying the 
issuer of that modem's SS certificate. 

7.6.3 Certificate processing and management in the BS 

PKM employs digital certificates to allow BSs to verify the binding between an SS's identity (encoded in an 
X.509 digital certificate's subject names) and its public key. The BS does this by validating the SS 
certificate's certification path or chain. Validating the chain means verifying the Manufacturer CA 
Certificate through some means. 
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8. PHY 

8.1 WirelessMAN-SC PHY specification 

8.1.1 Overview 

This PHY specification, targeted for operation in the 10-66 GHz frequency band, is designed with a high 
degree of flexibility in order to allow service providers the ability to optimize system deployments with 
respect to cell planning, cost, radio capabilities, services, and capacity. 

In order to allow for flexible spectrum usage, both TDD and FDD configurations (8.1.3) are supported. Both 
cases use a burst transmission format whose framing mechanism (8.1.4.1) supports adaptive burst profiling 
in which transmission parameters, including the modulation and coding schemes, may be adjusted 
individually to each SS on a frame-by-frame basis. The FDD case supports full-duplex SSs as well as half- 
duplex SSs, which do not transmit and receive simultaneously. 

The uplink PHY is based on a combination of TDMA and DAMA. In particular, the uplink channel is 
divided into a number of time slots. The number of slots assigned for various uses (registration, contention, 
guard, or user traffic) is controlled by the MAC in the BS and may vary over time for optimal performance. 
The downlink channel is TDM, with the information for each SS multiplexed onto a single stream of data 
and received by all SSs within the same sector. To support half-duplex FDD SSs, provision is also made for 
a TDMA portion of the downlink. 

The downlink PHY includes a Transmission Convergence sublayer that inserts a pointer byte at the 
beginning of the payload to help the receiver identify the beginning of a MAC PDU. Data bits coming from 
the Transmission Convergence sublayer are randomized, FEC encoded, and mapped to a QPSK, 16 
quadrature amplitude modulation (QAM), or 64-QAM (optional) signal constellation. 

The uplink PHY is based upon TDMA burst transmission. Each burst is designed to carry variable-length 
MAC PDUs. The transmitter randomizes the incoming data, FEC encodes it, and maps the coded bits to a 
QPSK, 16-QAM (optional), or 64-QAM (optional) constellation. 

8.1 .2 Framing 

This PHY specification operates in a framed format (6.3.7). Within each frame are a downlink subframe and 
an uplink subframe. The downlink subframe begins with information necessary for frame synchronization 
and control. In the TDD case, the downlink subframe comes first, followed by the uplink subframe. In the 
FDD case, uplink transmissions occur concurrently with the downlink frame. 

Each SS shall attempt to receive all portions of the downlink except for those bursts whose burst profile is 
either not implemented by the SS or is less robust than the SS's current operational downlink burst profile. 
Half-duplex SSs shall not attempt to listen to portions of the downlink coincident with their allocated uplink 
transmission, if any, adjusted by their Tx time advance. 

8.1.2.1 Supported frame durations 

Table 136 indicates the supported frame durations. 

8.1.3 Duplexing techniques and PHY Type parameter encodings 

Both FDD and TDD are supported. The duplexing method shall be reflected in the PHY Type parameter 
(11.4.1) as shown in Table 137. 
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Table 136— Frame durations and frame duration codes 



Frame duration code (4 bits) 


Frame duration (T F ) 


Units 


0x01 


0.5 


ms 


0x02 


1 


ms 


0x03 


2 


ms 


0x04 - OxOF 


reserved 





Table 137— PHY Type parameter encoding 



PHY Type 


Value 


TDD 


0 


FDD 


1 



8.1.3.1 FDD operation 

In FDD operation, the uplink and downlink channels are on separate frequencies. The capability of the 
downlink to be transmitted in bursts facilitates the use of different modulation types and allows the system to 
simultaneously support full-duplex SSs (which can transmit and receive simultaneously) and half-duplex 
SSs (which do not). Note that the downlink carrier may be continuous, as demonstrated in Figure 138 (third 
frame). Figure 138 describes the basics of the FDD operation. 

In the case of a half-duplex SS, transition gaps, as described in 8.1.3.2.1 and 8.L3.2.2, apply. 



Downlink 



Uplink 



time 




frame 



Broadcast 













■ 









Half Duplex SS #1 



Full Duplex Capable SS jjjj Half Duplex SS #2 
Figure 138— Example of FDD bandwidth allocation 
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8.1.3.2 TDD operation 

In the case of TDD, the uplink and downlink transmissions share the same frequency but are separated in 
time, as shown in Figure 139. A TDD frame also has a fixed duration and contains one downlink and one 
uplink subframe. The TDD framing is adaptive in that the link capacity allocated to the downlink versus the 
uplink may vary. 



n = (Symbol Rate x Frame Duration) / 4 



Downlink Subframe 



Uplink Subframe 




PSO 



PS n-1 



Frame /-2 


Frame /-1 


Frame j 


Frame y+1 


Frame /* 2 



Figure 139— TDD frame structure 



8.1 .3.2.1 TTG 

The TTG is a gap between the downlink burst and the subsequent uplink burst. This gap allows time for the 
BS to switch from transmit to receive mode and SSs to switch from receive to transmit mode. During this 
gap, the BS and SS are not transmitting modulated data but simply allowing the BS transmitter carrier to 
ramp down, the transmit/receive (Tx/Rx) antenna switch to actuate, and the BS receiver section to activate. 
After the gap, the BS receiver shall look for the first symbols of uplink burst. This gap is an integer number 
of PS durations and starts on a PS boundary. 

8.1.3.2.2 RTG 

The RTG is a gap between the uplink burst and the subsequent downlink burst. This gap allows time for the 
BS to switch from receive to transmit mode and SSs to switch from transmit to receive mode. During this 
gap, the BS and SS are not transmitting modulated data but simply allowing the BS transmitter carrier to 
ramp up, the Tx/Rx antenna switch to actuate, and the SS receiver sections to activate. After the gap, the SS 
receivers shall look for the first symbols of QPSK modulated data in the downlink burst. This gap is an 
integer number of PS durations and starts on a PS boundary. 

8.1.4 Downlink PHY 

The available bandwidth in the downlink direction is defined with a granularity of one PS. The available 
bandwidth in the uplink direction is defined with a granularity of one minislot, where the minislot length is 
2 m PSs (m ranges from 0 through 7). The number of PSs with each frame is a function of the symbol rate. 
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The symbol rate is selected in order to obtain an integral number of PSs within each frame. For example, 
with a 20 MBd symbol rate, there are 5000 PSs within a 1 ms frame. 

8.1.4.1 Downlink subframe 

The structure of the downlink subframe using TDD is illustrated in Figure 140. The downlink subframe 
begins with a Frame Start Preamble used by the PHY for synchronization and equalization. This is followed 
by the frame control section, containing DL-MAP and UL-MAP stating the PSs at which bursts begin. The 
following TDM portion carries the data, organized into bursts with different burst profiles and therefore 
different level of transmission robustness. The bursts are transmitted in order of decreasing robustness. For 
example, with the use of a single FEC type with fixed parameters, data begins with QPSK modulation, 
followed by 16-QAM, followed by 64-QAM. In the case of TDD, a TTG separates the downlink subframe 
from the uplink subframe. 

Each SS receives and decodes the control information of the downlink and looks for MAC headers 
indicating data for that SS in the remainder of the downlink subframe. 



\ 

TTG 



TDM Portion 



Preamble 


Broadcast 
Control 
DIUC = 0 


TDM 
DIUCa 


TDM 
DIUCb 


TDM 
DIUCc 











] 




amble 






DL-MAP 


UL-MAP 


CD 

at 







Figure 140 — TDD downlink subframe structure 



In the FDD case, the structure of the downlink subframe is illustrated in Figure 141. Like the TDD case, the 
downlink subframe begins with a Frame Start Preamble followed by a frame control section and a TDM 
portion organized into bursts transmitted in decreasing order of burst profile robustness. This TDM portion 
of the downlink subframe contains data transmitted to one or more of the following: 

— Full-duplex SSs 

— Half-duplex SSs scheduled to transmit later in the frame than they receive 

— Half-duplex SSs not scheduled to transmit in this frame 

The FDD downlink subframe continues with a TDMA portion used to transmit data to any half-duplex SSs 
scheduled to transmit earlier in the frame than they receive. This allows an individual SS to decode a 
specific portion of the downlink without the need to decode the entire downlink subframe. In the TDMA 
portion, each burst begins with the Downlink TDMA Burst Preamble for phase ^synchronization. Bursts in 
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the TDMA portion need not be ordered by burst profile robustness. The FDD frame control section includes 
a map of both the TDM and TDMA bursts. 




The TDD downlink subframe, which inherently contains data transmitted to SSs that transmit later in the 
frame than they receive, is identical in structure to the FDD downlink subframe for a frame in which no half- 
duplex SSs are scheduled to transmit before they receive. 

8.1.4.1.1 Downlink burst preambles 

As shown in Table 138, two downlink burst preambles are used. The Frame Start Preamble shall begin each 
downlink frame. The Downlink TDMA Burst Preamble shall begin each TDMA burst in the TDMA portion 
of the downlink subframe. 



Table 138 — Downlink burst preambles 



Preamble name 


Burst profile 


Preamble type 


Modulation type 


Frame Start Preamble 


TDM Burst 


1 


QPSK 


Downlink TDMA Burst Preamble 


TDMA Burst 


2 


QPSK 



Both preambles use QPSK modulation and are based upon +45 degrees rotated constant amplitude zero 
autocorrelation (CAZAC) sequences (Milewski [B38]). The amplitude of the preamble shall depend on the 
downlink power adjustment rule (8.1.4.4.7). In the case of the constant peak power scheme (power 
adjustment rule = 0), the preamble shall be transmitted such that its constellation points coincide with the 
outermost constellation points of the modulation(s) scheme in the burst. In the case of the constant mean 
power scheme (power adjustment rule = 1), it shall be transmitted with the mean power of the constellation 
points of the modulation scheme(s) in the burst. 
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The Frame Start Preamble (Table 139) consists of a 32-symbol sequence generated by repeating a 
16-symbol CAZAC sequence. The Downlink TDMA Burst Preamble (Table 140) consists of a 16-symbol 
sequence generated by repeating an 8-symbol CAZAC sequence. 



Table 139— Frame start preamble 



Symbol 


I 


Q 


B(l) 


B(2) 


1 and 17 


1 


! 


0 


0 1 


2 and 18 


! 


! 


0 


0 


3 and 19 


_! 


j 


1 


0 


4 and 20 


_! 


_! 


1 


1 


5 and 21 


_! 


! 


1 


0 


6 and 22 


! 




0 


1 


7 and 23 


_! 


! 


1 


0 


8 and 24 


1 


1 


0 


0 


9 and 25 






1 


1 


10 and 26 






1 


1 


11 and 27 






1 


0 


12 and 28 






1 


1 


13 and 29 






0 


1 


14 and 30 






1 


0 


15 and 31 






1 


0 


16 and 32 






0 


0 



Table 140— Downlink TDMA burst preamble 



Symbol 


I 


Q 


B(l) 


B(2) 


1 and 9 


-1 




1 


1 


2 and 10 


-1 




1 


0 


3 and 11 


-1 




1 


1 


4 and 12 


1 




0 


0 


5 and 13 


1 




0 


0 


6 and 14 


-1 




1 


0 


7and 15 


1 




0 


0 


8 and 16 


1 




0 


0 
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8.1.4.1.2 Frame control section 

The frame control section is the first portion of the downlink frame following the preamble. It is used for 
control information destined for all SSs. This control information shall not be encrypted. The information 
transmitted in this section always uses the well-known downlink burst profile with DIUC=0. 

The frame control section shall contain a DL-MAP message (6.3.2.3.2) for the channel followed by one UL- 
MAP message (6.3.2.3.4) for each associated uplink channel. In addition, it may contain DCD and UCD 
messages (6.3.2.3.1 and 6.3.2.3.3) following the last UL-MAP message. No other messages shall be sent in 
the frame control section. 

8.1.4.1.2.1 DL-MAP elements 

The IEs as defined in Table 141 follow the Number of DL-MAP Elements field of the DL-MAP message, as 
described in 6.3.2.3.2. The Map IEs shall be in chronological order. Note that this is not necessarily DIUC 
order (as DIUC numbering does not necessarily reflect robustness of the burst profile) or CID order. 



Table 141— SC DL-MAP JE 



Syntax 


Size 


Notes | 


DL-MAP_IE() { 






DIUC 


4 




StartPS 


16 


The starting point of the burst, 
in units of PS where the first PS 
in a given frame has StartPS=0 


if (CID use enabled- by burst profile) { 






CID 


16 bits 


Unicast, multicast, or broadcast 
value 


} 






} 







8.1.4.1.2.2 DL-MAP PHY synchronization field definition 

The format of the PHY Synchronization Field of the DL-MAP message, as described in 63.2.3.2, is given in 
Table 142. 

Network Configuration Type 

Defines the network configuration type. If the network is DM then an FCH expected field is 
included. This is a 16-bit field that defines when the frame preamble and FCH will next be 
transmitted. As this transmission will be directed to a given SS, it is effectively a private 
transmission to that SS. 

Frame Duration Code 
Defined in Table 136. 

Frame Number 

Incremented by 1 each frame and eventually wraps around to zero. 
FCH expected 

The FCH expected will indicate the transmission of a DL-MAP, UL-MAP, DCD or UCD. For 
network entry of DM it is possible to increase the frequency of occurrence of FCH transmission to 
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assist new nodes to enter the network. The frequency can be reduced for the case of steady state 
network operation. 



Table 142— SC PHY synchronization field 



Syntax 


Size 


Notes 


PHY Synchronization FieldQ { 






Network Configuration Type (NCT) 


4 bits 


Flag to indicate network 
configuration Type 

0 = PMP, 

1 — TWA 

1 = DM, 

2 = PtP, 

3-15 Reserved 


Frame Duration Code 


4 bits 




Frame Number 


24 bits 




if (NCT = DM) { 






FCH expected 


16 bits 


The number of frames before the 
Frame Preamble and FCH will be 
transmitted again. 1 


} 






} ' 







8.1 .4.1 .2.3 UL-MAP allocation start time definition 

The allocation start time is the effective start time of the uplink allocation defined by the UL-MAP in units 
of minislots. The start time is relative to the start of the frame in which the UL-MAP message is transmitted. 

8.1.4.1.2.4 Required DCD parameters 

The following parameters shall be included in the DCD message: 

— BS Transmit Power 

NOTE— to be used by SSs to validate radio link conditions 

— PHY type 

— FDD/TDD frame duration 

8.1 .4.1 .2.5 Downlink_Burst_Prof ile 

Each Downlink„Burst_Profile in the DCD message (6.3.2.3.1) shall include the following parameters: 

— Modulation type 

— FEC Code Type 

— Last codeword length 

— DIUC mandatory exit threshold 

— DIUC minimum entry threshold 

— Preamble Presence 



314 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



If the FEC Code Type is 1, 2, or 3 (RS codes), the Downlink_Burst_Profile shall also include 

— RS information bytes (K) 

— RS parity bytes (R) 

If the FEC Code Type is 2, the Downlink_Burst_Profile shall also include 

— BCC code type 

If the FEC Code Type is 4, the Downlink _Burst_Profile shall also include 

— Block Turbo Code (BTC) row code type 

— BTC column code type 

— BTC interleaving type 

The mapping between Burst Profile and DIUC is given in Table 143. 



Table 143— Mapping of burst profile to DIUC 



Burst profile 


DIUC 


Downlink Burst Profile 1 


0 


Downlink Burst Profile 2 


1 


Downlink Burst Profile 3 


2 


Downlink Burst Profile 4 


3 


Downlink Burst Profile 5 


4 


Downlink Burst Profile 6 


5 


Downlink Burst Profile 7 


6 


Downlink Burst Profile 8 


7 


Downlink Burst Profile 9 


8 


Downlink Burst Profile 10 


9 


Downlink Burst Profile 11 


10 


Downlink Burst Profile 12 


11 


Downlink Burst Profile 13 


12 


reserved 


13 


Gap 


14 


End of DL-MAP 


15 



The Downlink Burst Profile 1 (DIUC = 0) parameters defined in 8.1.4.4.5 shall be stored in the SS and shall 
not be included in the DCD message. 

The Gap Downlink Burst Profile (DIUC = 14) indicates a silent interval in downlink transmission. It is 
well-known and shall not be defined in the DCD message. 
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The End of DL-MAP Burst Profile (DIUC = 15) indicates the first PS after the end of the downlink 
subframe. It is well known and shall not be included in the DCD message. 

Table 144 defines the format of the Downlink J3urstjProfile, which is used in the DCD message (6.3.2.3.1). 
The Downlink_Burst_Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit DIUC. The DIUC field 
is associated with the Downlink Burst Profile and Thresholds. The DIUC value is used in the DL-MAP 
message to specify the Burst Profile to be used for a specific downlink burst. 



Table 144— SC Downlink_Burst_Profile format 



Syntax 


Size 


Notes 


Type=l 


8 bits 




Length 


variable 




reserved 


4 bits 


Shall be set to zero 


DIUC 


4 bits 




TLV encoded information 


variable 


TLV Specific 



8.1 .4.2 Downlink burst allocation 

The downlink data sections are used for transmitting data and control messages to the specific SSs. The data 
are always FEC coded and are transmitted at the current operating modulation of the individual SS. In the 
TDM portion, data shall be transmitted in order of decreasing burst profile robustness. In the case of a 
TDMA portion, the data are grouped into separately delineated bursts that need not be in robustness order 
(see 8.1.4.1). The DL-MAP message contains a map stating at which PS the burst profile changes occur. In 
the case of TDMA, if the downlink data does not fill the entire downlink subframe, the transmitter is shut 
down. FEC codewords within a burst are arranged in a compact form aligned to bit-level boundaries. This 
implies that, while the first FEC codeword shall start on the first PS boundary, succeeding FEC codewords 
may start even within a modulation symbol or within a PS if the succeeding FEC codeword ended within a 
modulation symbol or within a PS. The exact alignment conditions depend on the burst profile parameters. 

In the case of shortening the last FEC block within a burst (optional, see 11.4.2), the DL-MAP provides an 
implicit indication. 

In general, the number of PSs i (which shall be an integer) allocated to a particular burst can be calculated 
from the DL-MAP, which indicates the starting position of each burst as well as the burst profiles. Let n 
denote the minimum number of PSs required for one FEC codeword of the given burst profile (note that n is 
not necessarily an integer). Then, i = kn +y + q, where k is the number of whole FEC codewords that fit in 
the burst, j (not necessarily an integer) is the number of PSs occupied by the largest possible shortened 
codeword, and q (0 < q < 1) is the number of PSs occupied by pad bits inserted at the end of the burst to 
guarantee that i is an integer. In Fixed Codeword Operation (8.1.4.4.4.1), j is always 0. Recall that a 
codeword can end partway through a modulation symbol as well as partway through a PS. When this occurs, 
the next codeword shall start immediately, with no pad bits inserted. At the end of the burst (i.e., when there 
is no next codeword), then 4q symbols are added as padding (if required) to complete the PS allocated in the 
DL-MAP. The number of padding bits in these padding symbols is 4q times the modulation density, where 
the modulation density is 2 for QPSK, 4 for 16-QAM, and 6 for 64-QAM. Note that padding bits may be 
required with or without shortening. Either k or y, but not both, may be zero. The number; implies some 
number of bits b. Assuming ; is nonzero, it shall be large enough such that b is larger than the number of 
FEC bits, r, added by the FEC scheme for the burst. The number of bits (preferably an integral number of 
bytes) available for user data in the shortened FEC codeword is b-r. Any bits that may be left over from a 
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fractional byte are encoded as binary 1 to ensure compatibility with the choice of OxFF for pad. A codeword 
cannot have less than six information bytes. This is illustrated in Figure 142. 



Number of modulation symbols = 4/ 



iiDiDiiiiiiiDisiDigiiisigigigiiiDiiiDiDiiiiiiiDiiiiii 




Number of PSs / = y- x= kn + j + q 



MINI 



n n *~4- 



j — +q 



FEC 


FEC 


FEC 


Codeword 


Codeword 


Codeword 



Shortened 

FEC 
Codeword 



\ 



Map entry m 
starts on PS = x 



b~r date, bits 



/-redundancy bits 



Remainder q 
(fraction of a PS) 
Aq padding symbols 



\ 



Map entry m±\ 
starts on PS = y 



yPSs = 6bits 



Figure 142— DL-MAP usage with shortened FEC blocks— TDM case 



In the case of TDMA downlink, a burst includes the Downlink TDMA Burst Preamble of length p PSs, and 
the DL-MAP entry points to its beginning (Figure 143). 

8.1.4.3 Downlink Transmission Convergence sublayer 

The downlink payload shall be segmented into blocks of data designed to fit into the proper codeword size 
after the CS pointer byte is added. Note that the payload length may vary, depending on whether shortening 
of codewords is allowed or not for this burst profile. A pointer byte shall be added to each payload segment, 
as illustrated in Figure 144. 





1 


f 


p 


MAC PDU that has 
started in the previous 
TC packet 


First MAC PDU that 
starts in this TC packet 


Second MAC PDU that starts 
in this TC packet 



< Transmission Convergence sublayer (TC) PDU ► 

P = 1 byte pointer field 



Figure 144— Format of the downlink Transmission Convergence sublayer PDU 
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Map entry m 
starts on PS = x 



Remainder q 
M ' (fraction of a PS) 
4q padding symbols 



Map entry m+1 
starts on PS = y 



/PSs = bits 



Figure 143— DL-MAP usage with shortened FEC blocks— TDM A case 

The pointer field identifies the byte number in the packet, which indicates either the beginning of the first 
MAC PDU to start in the packet or the beginning of any stuff bytes that precede the next MAC PDU. For 
reference, the first byte in the packet is referred to as byte number 1. If no MAC PDU or stuff bytes begin in 
the CS packet, then the pointer byte is set to 0. When no data is available to transmit, a stuff _byte pattern 
having a value (OxFF) shall be used within the payload to fill any gaps between the IEEE 802.16 MAC 
PDUs. This value is chosen as an unused value for the first byte of the IEEE 802.16 MAC PDU, which is 
designed to never have this value. 
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8.1.4.4 Downlink PMD sublayer 

The downlink PHY coding and modulation for this mode is summarized in the block diagram in Figure 145. 
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Figure 145— Conceptual block diagram of the downlink PMD sublayer 



8.1.4.4.1 Burst profile definitions 

The downlink channel supports adaptive burst profiling on the user data portion of the frame. Up to twelve 
burst profiles can be defined. The parameters of each are communicated to the SSs via MAC messages 
during the frame control section of the downlink frame (see 8.1.4.1). The downlink channel and burst 
profiles are communicated to the SSs via the MAC messages described in 6.3.2.3.1. 



The use of DIUCs shall be constrained as shown in Table 145. 



Table 145— SC DIUC allocation 



DIUC 


Usage 


0 


frame control (well known, not in DCD message) 


1-6 


TDM Burst Profiles (no preamble) 


7-12 


TDM A Burst Profiles (preamble prefixed) 


13 


reserved 


14 


Gap (well known, not in DCD message) 


15 


End of Map 



8.1.4.4.2 Downlink PHY SS capability set parameters 

Since there are optional modulation and FEC schemes that can be implemented at the SS, a method for 
identifying the capability to the BS is required (i.e., including the highest order modulation supported, the 
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optional FEC coding schemes supported, and the minimum shortened last codeword length supported). This 
information shall be communicated to the BS during the subscriber registration period. 



8.1.4.4.3 Randomization 



Randomization shall be employed to minimize the possibility of transmission of an unmodulated carrier and 
to ensure adequate numbers of bit transitions to support clock recovery. The stream of downlink packets 
shall be randomized by modulo-2 addition of the data with the output of the pseudo-random binary sequence 
(PRBS) generator, as illustrated in Figure 146. The generator polynomial for the PRBS shall be c(x) = x + 



initialization sequence 
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(MSB first) 
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data output 



Figure 146— Randomizer logic diagram 



At the beginning of each burst, the PRBS register is cleared and the seed value of 100101010000000 is 
loaded. A burst corresponds to either a TDM burst beginning with the Frame Start Preamble or a TDMA 
burst beginning with a Downlink TDMA Burst Preamble (8.1.4.1.1). The seed value shall be used to 
calculate the randomization bits, which are combined in an XOR operation with the serialized bit stream of 
each burst. The randomizer sequence is applied only to information bits. 

8.1.4.4.4 Downlink FEC 

The FEC schemes are selectable from the types in Table 146. 



Table 146— FEC Code Types 



Code Type 


Outer Code 


Inner Code 


1 


Reed-Solomon over Galois field (GF) (256) 


None 


2 


Reed-Solomon over GF(256) 


(24,16) Block convolutional code 


3 (Optional) 


Reed-Solomon over GF(256) 


(9,8) Parity check code 


4 (Optional) 


BTC 
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Implementation and use of Code Types 3 and 4 is optional. Code Types 1 and 2 shall be implemented by all 
BSs and SSs. Code Type 2 shall not be used except in the case of QPSK modulation. In the case of QPSK, 
any of the four Code Types may be used, with one exception: Code Type 2 shall always be used for the 
control channel (DIUC=0). 

Following is a summary of the four Code Types: 

a) Code Type 1: Reed-Solomon only: This case is useful either for a large data block or when high 
coding rate is required. The protection could vary between t = 0 to t = 16. 

b) Code Type 2: Reed-Solomon + Block convolutional code (soft decodable): This case is useful for 
low to moderate coding rates providing good carrier-to-noise ratio (C/N) enhancements. The coding 
rate of the inner block convolutional code (BCC) is 2/3. Note: The number of information bytes 
shall be even in this case. 

c) Code Type 3: Reed-Solomon + Parity check: This optional code is useful for moderate to high 
coding rates with small to medium size blocks (i.e., K = 16, 53, or 128). The code itself is a simple 
bit wise parity check operating on byte (8 bit) level. The parity code can be used for error correction, 
preferably employing a soft decoder. 

d) Code Type 4: ETC: This optional code is used to significantly lower the required carrier-to- 
interference ratio (C/I) level needed for reliable communication, and can be used to either extend the 
range of a BS or increase the code rate for greater throughput. 

8.1.4.4.4.1 Outer code for Code Types 1-3, downlink 

The outer block code for Code Types 1-3 shall be a shortened, systematic Reed-Solomon code generated 
from GF(256) with information block length K variable from 6-255 bytes and error correction capability T 
able to correct from 0 to 16 byte errors. The specified code generator polynomials are given by: 

Code Generator Polynomial: g(x) = (x + |i°)(jt + u. 1 )(x + jj, 2 ) ... (x + \i 2T ~ x ), where = 02 hex 
Field Generator Polynomial: p(x) = jc 8 + jc 4 + jc 3 + x 2 + 1 

The specified code has a block length of 255 bytes and shall be configured as an RS(255, 255-7?) code with 
information bytes preceded by (255-AT) zero symbols, where N is the codeword length and R the number of 
redundancy bytes (R = 2x7 ranges from 0 to 32, inclusive). 

The value of K and T are specified for each burst profile by the MAC. Both Fixed Codeword Operation and 
Shortened Last Codeword Operation, as defined below, are allowed. . . • 

When using Code Type 2, the number of information bytes K shall always be an even number so that the 
total codeword size (K+R) is also an even number. This is due to the fact that the BCC code requires a pair of 
bytes on which to operate. 

a) Fixed Codeword Operation 

In Fixed Codeword Operation, the number of information bytes K is the same in each Reed-Solomon 
codeword. If the MAC messages in a burst require fewer bytes than are carried by an integral number of 
codewords, stuff bytes (FF hex ) shall be added between MAC messages or after the last MAC message so that 
the total message length is an integral multiple of kbytes. 

The SS determines the number of codewords in its downlink burst from the DL-MAP message, which 
defines the beginning point of each burst, and hence the length. The BS determines the number of 
codewords in the downlink as it scheduled this transmission event and is aware about its length. Using the 
burst length, both the SS and the BS calculate the number of full-length RS codewords~that can be carried by 
each burst. 
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The process used by the BS to encode each burst is described below: 

When the number of randomized MAC message bytes (M) entering the FEC process is less than K bytes, 
Operation A shall be performed: 

Al) Add (K-M) stuff bytes (FF hex ) to the M byte block as a suffix. 
A2) RS encode the K bytes and append the R parity bytes. 

A3) Serialize the bytes and transmit them to the inner coder or the modulator most significant 
bit first. 

When the number of randomized MAC message bytes (M) entering the FEC process is greater than or equal 
to K bytes, Operation B shall be performed: 

Bl) RS encode the first K bytes and append the R parity bytes. 
B2) Subtract K from M (Let M = M - K). 

B3) If the new M is greater than or equal to K, then repeat with the next set of bytes (go to Bl). 
B4) If the new M is zero, then stop; otherwise go to step Al above and process the M<K case. 

b) Shortened Last Codeword Operation 

In the Shortened Last Codeword Operation, the number of information bytes in the final Reed-Solomon 
block of each burst is reduced from the normal number K, while the number of parity bytes R remains the 
same. The BS tailors the number of information bytes in the last codeword in order to minimize the number 
of stuff bytes to add to the end of the MAC message. The length of the burst is then set to the minimum 
number of PSs required to transport all of the burst's bytes, which include preamble, information, and parity 
bytes. The BS implicitly communicates the number of bytes in the shortened last codeword to the SS via the 
DL-MAP message, which defines the starting PS of each burst. The SS uses the DL-MAP information to 
calculate the number of full-length RS codewords and the length of the shortened last codeword that can be 
carried within the specified burst size. The BS performs a similar calculation as the SS for its encoding 
purposes. 

To allow the receiving hardware to decode the previous Reed-Solomon codeword, no Reed-Solomon 
codeword shall have less than 6 information bytes. The number of information bytes carried by the 
shortened last codeword shall be between 6 and K bytes, inclusive. If the number of information bytes 
needing to be sent by the BS is less than 6 bytes of data, stuff bytes (FF hex ) shall be appended to the end of 
the data to bring the total number of information bytes up to the minimum of 6. 

When using Code Type 2, the number of information bytes in the shortened last codeword shall always be an 
even number so that the total codeword size is also an even number. If an odd number of information bytes 
needs to be sent, a stuff byte (FF hex ) shall be appended to the end of the message to obtain an even number 
of bytes. 

The process used by the BS to encode each burst is described below: 

First, the full-sized Reed-Solomon codewords that precede the burst's final codeword are encoded as in the 
Fixed Codeword Mode above. The number of bytes allocated for the shortened last codeword by the UL- 
MAP is k' bytes, which shall be between 6 and K bytes. The remaining M bytes of the message are then 
encoded into these k' bytes using the following procedure: 

Al) Add (tf-fcO zero bytes to the M byte block as a prefix. 
A2) RS encode the K bytes and append the R parity bytes. 
A3) Discard all of the (#-*') zero RS symbols. 

A4) Serialize the bytes and transmit them to the inner coder or the modulator most significant 
bit first. 

AS) Perform the inner coding operation (if applicable). 



322 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



8.1.4.4.4.2 Inner code for Code Type 2, downlink 

The inner code in Code Type 2 consists of short block codes derived from a 4-state, nonsystematic, 
punctured convolutional code (7,5). The trellis shall use the tail-biting method, where the last 2 bits of the 
message block are used to initialize the encoder memory, in order to avoid the overhead required for trellis 
termination. Thus, the encoder has the same initial and ending state for a message block. 

For this concatenated coding scheme, the inner code message block is selected to be 16 bits. The puncturing 
pattern is described in Table 147 for the (24,16) case. 



Table 147— Parameters of the inner codes for the BCC 



Inner code rate 


Puncture pattern 
Gl = 7, G2 = 5 


2/3 


11, 10 



Figure 147 describes the exact encoding parity equations. 
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Figure 147— Inner code for Code Type 2 in the downlink 



The number of information bytes shall be even since the BCC code operates on byte pairs. 
8.1.4.4.4.3 Inner code for Code Type 3, downlink 

For Code Type 3, a parity check bit is added to each Reed-Solomon (RS) symbol individually and inserted 
as the LSB of the resulting 9-bit word. The parity is an XOR operation on all 8 bits within the symbol. 
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8.1.4.4.4.4 Code Type 4, downlink 

Code Type 4, the BTC, is a Turbo decoded Product Code (TPC). The idea of this coding scheme is to use 
extended Hamming block codes in a two-dimensional matrix. The two-dimensional code block is depicted 
in Figure 148. The k x information bits in the rows are encoded into n x bits, by using an extended Hamming 
binary block (n x ,k x ) code. Likewise, k y information bits in the columns are encoded into n y bits, by using the 
same or possibly different extended Hamming binary block (n y k y ) code. The resultant code block is com- 
prised of multiple rows and columns of the constituent extended Hamming block codes. 

For this standard, the rows shall be encoded first. After encoding the rows, the columns are encoded using 
another block code {n y k y \ where the check bits of the first code are also encoded. The overall block size of 
such a product code is n = n x x n y \ the total number of information bits k x x k y \ and the code rate is R = R x x 
R T where R t = and i = x or y. 



A A 



n 2 



information 
bits 


checks 


checks 


checks 
on 

checks 



Figure 148— Two-dimensional product code matrix 



Table 148 provides the generator polynomials of the constituent Hamming codes used in this specification. 



Table 148— SC Hamming code generator polynomials 



n 


k 


Generator polynomial 


31 


26 


x 5 +x 2 + \ 


63 


57 


x 6 +x+\ 



The composite extended Hamming code specified requires addition of an overall even parity check bit at the 
end of each codeword. 

The encoder for a BTC is composed of linear feedback shift registers (LFSRs), storage elements, and control 
logic. An example row (or column) encoder is shown here for clarification. The order of transmission is 
important so that the decoder may match for proper decoding. This specification mandates that the resultant 
code block be transmitted row by row, left to right, top to bottom, for the case when no interleaving is used 
(Interleaver Type 1 described below). 
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Figure 149 shows a sample LFSR based on a x 4 + x + 1 Hamming code polynomial to encode a (15,11) 
Hamming code. Also shown is an even parity computation register that results in an extended Hamming 
code. Note that encoders for the required (64,57) and (32,26) codes follow the same design concept. This 
figure is shown for clarification of the BTC encoder design and does not depict an actual design 
implementation. 
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Figure 149 — Example encoder for a (16,11) extended Hamming Code 

The example circuit begins with all toggle switches in position A. Data to be encoded is fed as input one bit 
per clock (LSB first) to both the Hamming error correction code (ECC) computation logic and the overall 
even parity computation logic. Extended Hamming codes are systematic codes, so this data is also fed 
through as output on the encoded bit output. After all k bits are input, the toggle switches are moved to 
position B. At this point, data from the Hamming ECC logic is shifted out on the encoded bits bus. Finally, 
the overall parity bit is shifted out when the output select switch is moved to position C. 



In order to encode the product code, each data bit is fed as input both into a row LFSR and a column LFSR. 
Note that only one row LFSR is necessary for the entire block, since data is written as input in row order. 
However, each column of the array shall be encoded with a separate LFSR. Each column LFSR is clocked 
for only one bit of the row, so a more efficient method of column encoding is to store the column LFSR 
states in a k x x (n y - k y ) storage memory. A single LFSR can then be used for all columns of the array. With 
each bit input, the appropriate column LFSR state is read from the memory, clocked, and written back to the 
memory. 



The encoding process is demonstrated here with an example. Assume a two-dimensional (8,4)x(8,4) 
extended Hamming product code is to be encoded. This block has 16 data bits, and 64 total encoded bits. 
Table 149 shows the original 16 data bits denoted by D yx > where y corresponds to a column and x 
corresponds to a row. 

The first four bits of the array are fed into the row encoder input in the order D n , Z) 2 l> ^3l> ^41- Each mt IS 
also fed as input into a unique column encoder. Again, a single column encoder may be used, with the state 
of each column stored in a memory. After the fourth bit is fed into the input, the first row encoder ECC bits 
are shifted out. 



This process continues for all four rows of data. At this point, 32 bits have been taken as output from the 
encoder, and the four column encoders are ready to shift out the column ECC bits. This data is shifted out at 
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Table 149— Original data for encoding 



On 


021 


D 31 


D41 ! 


D n 


D 2 2 


032 


£> 42 


D 13 


023 


D 33 


Z> 43 


D 14 


D u 


D 34 


D44 



the end of the row. This continues from the remaining three rows of the array. Table 150 shows the final 
encoded block with the 48 generated ECC bits denoted by E yx . 



Table 150— Encoded block 





£>21 


031 


041 


£51 


£61 


£71 


£ 81 ] 


D\i 


D 22 


032 


042 


£52 


£ 6 2 


£72 


E %2 


D 13 


D 2 3 


033 


043 


£53 


£63 


£73 


E S3 


Du 


024 


034 


044 


£54 


E (A 


£74 


£ 84 


E l5 


£ 25 


£35 


£45 


£55 


£65 


£75 


E &5 


El6 


E 2 6 


*36 


£ 46 


£ 5 6 


£66 


£76 


E&6 


En 


E 21 


% 


£47 


£57 


£67 


£77 


£ 87 


E\» 


E 2i 


£ 38 


£ 48 


£ 5 8 


£ 68 


£78 


£88 



Transmission of the block over the channel occurs in a linear manner; all bits of the first row are transmitted 
left to right, followed by the second row, etc. This allows for the construction of a near zero-latency encoder, 
since the data bits can be sent immediately over the channel, with the ECC bits inserted as necessary. For the 
(8,4)x(8,4) example, the output order for the 64 encoded bits is D w D 21 , £> 31 , D 41 , £ 51 , E 6i , E 1V £ 81 , D 12 , 

#22> ••• ^88- 

For easier readability, the following notation is used: 

— The codes defined for the rows (x-axis) are binary (n x ,k x ) block codes. 

— The codes defined for the columns (y-axis) are binary {n y ky) block codes. 

— Data bits are noted D yx and parity bits are noted E yx . 

a) Shortened BTC: To match packet sizes, removing symbols from the array shortens a product code. 
In general, rows or columns are removed until the appropriate size is reached. Codes selected shall 
have an integral number of information bytes. Different shortening approaches are applicable for 
BTC. In one method, rows and columns are deleted completely from an initial BTC array. For 
example, a 253 byte code is generated by starting with (64,57) constituent codes and deleting 
thirteen rows and eleven columns. Another method uses a more systematic two-dimensional 
shortening. For example, a 128 byte BTC code is composed of (64,57) constituent codes which are 
shortened by 25 rows and 25 columns, as described in Figure 150. The end result is a 
(39,32)x(39,32) array, which is capable of encoding 32 x 32 = 1024 bits (128 bytes) of data. 
Table 151 summarizes these example codes. A method for determining codes for pay load sizes 
different than these examples is given at the end of this subclause. 
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Figure 150— Structure of shortened 2 D block 



Modifications to the encoder to support shortening are minimal. Since shortened bits are always zero, and 
zeros input to the encoder LFSR result in a zero state, the shortened bits can simply be ignored for the. 
purpose of encoding. The encoder simply needs to know how many bits per row to input to the row LFSR 
before shifting out the result. Similarly, it must know the number of columns to input to the column 
encoders. 

Transmission of the resultant code block shall start with the first data bit in the first row, proceed left to right 
and then row by row from top to bottom. 



Table 151— Required block codes for the BTC option for the downlink channel 



Code 


(39,32)X(39,32) 


(53,46)X(51,44) 


Aggregate Code Rate 


0.673 


0.749 


Uplink/Downlink/Both 


Downlink 


Downlink 


Block size (payload bits) 


1024(128 bytes) 


3136 (392 bytes) 



b) Interleaving: When using the Block Turbo Coding, two modes of bit interleaving shall be supported. 
The interleaver mechanism shall be implemented by writing information bits into the encoder 
memory and reading out the encoded bits as follows: 

1) Interleaver type I: No interleaver. In this mode, the encoded bits are read from the encoder row 
by row, in the order that they were written. 

2) Interleaver type 2: Block interleaver. In this mode, the encoded bits are read from the encoder 
after the first k 2 rows (Figure 148) are written into the encoder memory. The bits are read 
column by column, proceeding from the top position in the first column. 

3) Interleaver type 3: Reserved. It is expected that other interleaving methods may yield better 
performance in some cases. So, this Interleaver type 3 has been reserved for future definition. 

c) Block mapping to the signal constellation: The first encoded bit out shall be the LSB, which is the 
first bit written into the encoder. 
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d) Method for determining codes for payload size different than the listed examples: The following text 
describes a method for performing additional codeword shortening when the input block of data 
does not match exactly the codeword information size. 

1) Take the required payload as specified in bytes and convert it to bits (i.e., multiply by 8). 

2) Take the square root of the resultant number. 

3) Round the result up to the next highest integer. 

4) Select the smallest base constituent code from the available list that has a k value equal to or 
greater than the value determined in step 3). 

5) Subtract the value determined in step 3) from the k value selected in step 4). This value 
represents the number of rows and columns that need to be shortened from the base constituent 
code selected in step 4). 

This method will generally result in a code block whose payload is slightly larger than required in step 1 
above. In order to address the residual bits, the column dimension (n r k y ) should be shortened as needed and, 
as needed, zero bits may be stuffed into the last bits of the last row of the resulting code matrix. The zero bits 
in the last row should be discarded at the receiver. 

Example: If a 20 byte payload code is desired, a (32,26)x(32,26) code is shortened by 13 rows and by 13 
columns, resulting in a (19,13)x(19,13) code. There are 9 bits left over that are stuffed with zeros. Data input 
to the defined encoder is 160 data bits followed by 9 zero bits. The code block is transmitted starting with 
the bit in row 1 column 1 (the LSB), then left to right, and then row by row. 

8.1.4.4.5 Definition of parameters for burst profile (DIUC=0) 

The burst profile with DIUC=0 shall be configured with the parameters in Table 152. 



Table 152— Parameters for burst profile (DIUC=0) 



Parameter 


Value 


Comment 


Modulation type 


1 


QPSK 


FEC Code Type 


2 


RS + BCC 


RS information bytes (K) 


26 




RS parity bytes (R) 


20 




BCC Code Type 


1 


(24,16) 


Last codeword length 


1 


fixed 



8.1.4.4.6 Coding of the control portion of the frame 

The frame control section of the downlink frame (as defined in 8.1.4.1) shall be encoded with a fixed set of 
parameters known to the SS at initialization in order to ensure that all SSs can read the information. The 
modulation shall be QPSK, and the data shall be encoded with an outer (46,26) Reed-Solomon code and an 
inner (24,16) convolutional code. There shall be a minimum of two codewords per control portion of the 
frame when a downlink allocation map is present. When a UL-MAP is present, it shall be concatenated with 
the Downlink Allocation map to increase efficiency. This operation mode shall be designated as TDM Burst 
Profile 1 (DIUC = 0). Stuff bytes (FF hex ) shall be appended as necessary to the end of the control messages 
to fill up the minimum number of codewords. 
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8.1.4.4.7 Downlink modulation 

To maximize utilization of the airlink, the PHY uses a multilevel modulation scheme. The modulation 
constellation can be selected per subscriber based on the quality of the RF channel. If link conditions permit, 
then a more complex modulation scheme can be utilized to maximize airlink throughput while still allowing 
reliable data transfer. If the airlink degrades over time, possibly due to environmental factors, the system can 
revert to the less complex constellations to allow more reliable data transfer. 

In the downlink, the BS shall support QPSK and 16-QAM modulation and, optionally, 64-QAM. 

The sequence of modulation bits shall be mapped onto a sequence of modulation symbols S(&), where k is 
the corresponding symbol number. The number of bits per symbol depends on the modulation type. For 
QPSK, n = 2; for 16-QAM, n = 4; and for 64-QAM, n = 6. B(m) denotes the modulation bit of a sequence to 
be transmitted, where m is the bit number (m ranges from 1 through n). In particular, B(l) corresponds to the 
first bit entering the modulator, B(2) corresponds to the second bit entering the modulation, and so on. 

In changing from one burst profile to another, the BS shall use one of two power adjustment rules: 
maintaining constant constellation peak power (power adjustment rule = 0), or maintaining constant 
constellation mean power (power adjustment rule = 1). In the constant peak power scheme, corner points are 
transmitted at equal power levels regardless of modulation type. In the constant mean power scheme, the 
signal is transmitted at equal mean power levels regardless of modulation type. The power adjustment rule is 
configurable through the DCD Channel Encoding parameters (11.4.1). 

At the end of each burst, the final FEC-encoded message might not end exactly on a PS boundary. If this is 
the case, the end of the encoded message to the start of the next burst shall be filled with zero bits. 

The complex modulation symbol S(k) shall take the value / + jQ. The following subclauses apply to the 
base-band part of the transmitter. 

Figure 151 and Table 153 describe the bit mapping for QPSK modulation. 
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Figure 151 — QPSK constellation 
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Table 153— QPSK bits to symbol mapping 



B(l) 


B(2) 


I 


Q 


0 


0 


1 


l 


0 


1 


1 


-i 


1 


0 


-1 


l 


1 


1 


-1 


-l 



Figure 152 and Table 154 describe the bit mapping for 16-QAM modulation. 
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Figure 152— 16-QAM constellation (gray-coded) 
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B(l) 


B(2) 


B(3) 


B(4) 


I 


Q 


0 


1 


0 


1 


3 


3 


0 


1 


0 


0 


3 


1 j 


0 


1 


1 


0 


3 


-1 


0 


1 


1 


1 


3 


-3 


0 


0 


0 


1 


1 


3 


0 


0 


0 


0 


1 


1 


0 


0 


1 


0 


1 


-1 


0 


0 


1 


1 


1 


-3 


1 


0 


0 


1 


-1 


3 


1 


0 


0 


0 


-1 


1 


1 


0 


1 


0 


-1 


-1 




0 


1 


1 




-3 
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3 
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Figure 153 and Table 155 describe the bit mapping for 64-QAM modulation. 
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Figure 153— 64-QAM constellation (gray-coded) 
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Table 155— 64-QAM bits to symbol mapping 



B(l) 


B(2) 


B(3) 


B(4) 


B(5) 


B(6) 


I 
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1 


1 


0 


1 


1 


7 


7 


0 


1 


1 


0 


1 


0 


7 


5 


0 


1 


1 


0 


0 


0 


7 


3 
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1 


1 


0 


0 


1 


7 


1 


0 


1 


1 


1 


0 


1 


7 


-1 


0 


1 


1 


1 


0 


0 


7 


-3 


0 


1 


1 


1 


1 


0 


7 


-5 


. 0 
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Table 155— 64-QAM bits to symbol mapping (continued) 



B(l) 


B(2) 


B(3) 


B(4) 


B(5) 


B(6) 


I 


Q 


1 


0 


1 


0 


1 


0 


-1 


5 


1 1 


0 




0 


0 


0 


-1 


3 


1 


0 




0 


0 


1 


-1 


1 


1 


0 


1 


1 


0 


1 


-1 


-1 


1 


0 


1 


1 


0 


0 


-1 


-3 


1 


0 


1 


1 


1 


0 


-1 


-5 


1 


0 


1 


1 


1 


1 


-1 


-7 
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-3 


7 
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8.1 .4.4.8 Baseband pulse shaping 

Prior to modulation, the / and Q signals shall be filtered by square-root raised cosine filters. The excess 
bandwidth factor a shall be 0.25. The ideal square-root raised cosine filter is defined by the following 
transfer function H, as shown in Equation (12): 



H(f) = l 



1 I 
H(f)= I + sin 



2 2 

H(f) = 0 



n r f N -\f\\ 



forl/l^d-oc) 
for/ N (l-a)<|/| <f N (l+a) 
for |/| >/„(! + a) 



(12) 



1 R 

where f N = ^- = y is the Nyquist frequency. 



8.1.4.4.9 Transmitted waveform 

The transmitted waveform at the antenna port S(t) shall be: 

5(0 = I(t)cos(2nf c t) - Q(t)sm(2nf c t) (13) 

where /(/) and Q(t) are the filtered baseband (pulse- shaped) signals of the I k and Q k symbols, k is the 
discrete symbol index, and/ c is the carrier frequency. 



8.1 .5 Uplink PHY 
8.1.5.1 Uplink subframe 

The structure of the uplink subframe used by the SS to transmit to the BS is shown in Figure 154. Three 
classes of bursts may be transmitted by the SS during the uplink subframe: 

a) Those that are transmitted in contention opportunities reserved for Initial Ranging. 

b) Those that are transmitted in contention opportunies defined by Request Intervals reserved for 
response to multicast and broadcast polls. 

c) Those that are transmitted in intervals defined by Data Grant IEs specifically allocated to individual 
SSs. 

Any of these burst classes may be present in any given frame. They may occur in any order and any quantity 
(limited by the number of available PSs) within the frame, at the discretion of the BS uplink scheduler as 
indicated by the UL_MAP in the frame control section (part of the downlink subframe). 

The bandwidth allocated for Initial Ranging and Request contention opportunies may be grouped together 
and is always used with the uplink burst profiles specified for Initial Ranging Intervals (UIUC = 2) and 
Request Intervals (UIUC = 1), respectively. The remaining transmission slots are grouped by the SS. During 
its scheduled bandwidth, an SS transmits with the burst profile specified by the BS. 

SSTGs separate the transmissions of the various SSs during the uplink subframe. The gap allows for 
ramping down of the previous burst, followed by a preamble allowing the BS to synchronize to the new SS. 
The preamble and gap lengths are broadcast periodically in the UCD message. 
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Figure 154— Uplink subframe structure 



8.1 .5.1 .1 Uplink burst preamble 

Each uplink burst shall begin with an uplink preamble. This preamble is based upon a repetition of a 445 
degrees rotated constant amplitude zero auto-correlation (CAZAC) sequence (Milewski [B38]). The 
preamble length is either 16 symbols or 32 symbols. In the 16-symbol preamble (whose sequence is 
specified in Table 156), the CAZAC sequence is of length 8 and repeated once. In the 32- symbol preamble 
(whose sequence is specified in Table 157), the CAZAC sequence is of length 16 and repeated once. 



Table 156 — 16-symbol uplink preamble sequence 



Symbol 


/ 


Q 


*(i) 


B(2) 


1 and 9 


1 


l 


0 


0 


2 and 10 


-1 


-l 


i 


1 


3 and 11 


-1 


l 


l 


0 


4 and 12 


1 


l 


0 


0 


5 and 13 


1 


l 1 


0 


0 


6 and 14 


1 


l 


0 


0 


7 and 15 


-1 


l 


1 


0 


8 and 16 


-1 


-l 


1 


1 



The amplitude of the preamble shall depend on the uplink power adjustment rule (8.1.5.3.7). In the case of 
the constant peak power scheme (power adjustment rule = 0), the preamble shall be transmitted such that its 
constellation points coincide with the outermost constellation points of the modulation scheme in use. In the 
case of the constant mean power scheme (power adjustment rule = 1), it shall be transmitted with the mean 
power of the constellation points of the modulation scheme in use. 

The BS defines the preamble length through the UCD message. 
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Table 157— 32-symbol uplink preamble sequence 



Symbol 


/ 


Q 


B(l) 


B(2) 


1 and 17 


-1 


-l 


1 


1 


2 and 18 


-1 


-l 


1 


1 


3 and 19 


1 


l 


0 


0 


4 and 20 


1 


l 


0 


0 


5 and 21 


-1 


-l 


1 


1 


6 and 22 


1 


l 


0 


0 


7 and 23 


1 


-l 


0 


1 


8 and 24 


1 


l 


0 


0 


9 and 25 


1 


-l 


0 


1 


10 and 26 


-1 


-l 


1 


1 


11 and 27 


-1 


-i 


1 


1 


12 and 28 






0 


0 


13 and 29 






0 


0 


14 and 30 






0 


0 


15 and 31 






1 


0 


16 and 32 






0 


0 ! 



8.1.5.1.2 UL-MAPJE definition 

The format of UL-MAP_IEs shall be as defined in Table 158 and utilized according to 63.2.3.4. The UIUC 
shall be one of the values defined in Table 159. The Offset indicates the start time, in units of minislots, of 
the burst relative to the Allocation Start Time given in the UL-MAP message. The end of the last allocated 
burst is indicated by allocating an End of map burst (CID = 0 and UIUC = 10) with zero duration. The time 
instants indicated by the offsets are the transmission times of the first symbol of the burst, including the 
preamble. 



Table 158— SC UL-MAPJE format 



Syntax 


Size 


Notes 


UL-MAP JE0 { 






CID 


16 bits 




UIUC 


4 bits 




if (UIUC =15){ 






Extended UIUC dependent IE 


variable 


See subclauses following 
8.1.5.1.2.1 


} else { 






Offset 


12 bits 


Offset, in units of minislots, 
of the preamble relative to 
the Allocation Start Time 


} 






} 
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Table 159— SC UIUC values 



IE name 


UIUC 


Connection 
ID 


Description 




0 


N/A 


reserved 


Request 


1 


any 


Starting offset of request region. 


Initial 
Ranging 


2 


broadcast 


Starting offset of maintenance region (used in Initial Ranging). 




3 


N/A 


reserved 


Data Grant 
Burst Type 1 


4 


unicast 


Starting offset of Data Grant Burst Type 1 assignment. 


Data Grant 
Burst Type 2 


5 


unicast 


Starting offset of Data Grant Burst Type 2 assignment. 


Data Grant 
Burst Type 3 


6 


unicast 


Starting offset of Data Grant Burst Type 3 assignment. j 


Data Grant 
Burst Type 4 


7 


unicast 


Starting offset of Data Grant Burst Type 4 assignment. 


Data Grant 

Rnrct T\/r»#» ^ 

Diirai lype D 


8 


unicast 


Starting offset of Data Grant Burst Type 5 assignment. 


Uala VJIcillL 

Burst Type 6 


9 


unicast 


Starting offset of Data Grant Burst Type 6 assignment. 


End of map 


10 


zero 


Ending offset of the previous grant. 

Indicates the first minislot after the end of the uplink allocation. 
The burst profile is well known and shall not be included in the 
UCD message. Used to bound the length of the last actual interval 
allocation. 


Gap 


11 


zero 


Used to schedule gaps in transmission. 




12-14 


N/A 


reserved 


Extended 


15 


N/A 


See 8.1.5.1.2.1. 



8.1.5.1.2.1 UL-MAP extended IE format 

A UL-MAP IE entry with a UIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 160. A station shall ignore an extended IE entry with a subcode value for 
which the station has no knowledge. In the case of a known subcode value but with a length field longer than 
expected, the station shall process information up to the known length and ignore the remainder of the IE. 

Table 160— SC UL-MAP extended IE format 



Syntax 


Size 


Notes 


UL_Extended_IE() { 






Subcode 


4 bits 


0x00.. OxOF 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 
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8.1.5.1.2.2 UL-MAP Power Control IE format 

When a power change for the SS is needed, the extended UIUC = 15 is used with the subcode set to 0x00 as 
shown in Table 161. The power control value is an 8-bit signed integer expressing the change in power level 
(in 0.25 dB units) that the SS should apply to correct its current transmission power. The CID used in the IE 
shall be the Basic CID of the SS. 



Table 161— SC Power Control IE format 



Syntax 


Size 


Notes 


Power_Control_IE() { 






Extended UIUC 


4 bits 


Fast power control = 0x00 


Length 


4 bits 


Length = 1 


Power control 

} 


8 bits 


Signed integer, which expresses the change in 
power level (in 0.25 dB units) that the SS 
should apply to correct its current transmission 
power. 



8.1.5.1.3 Required UCD parameters 

The following parameters shall be included in the UCD message: 

— Preamble Length 

The following parameters may be included in the UCD message and if absent shall have their default values: 

— SSTG 

— Roll-off Factor 

Uplink Symbol Rate and Frequency are implied by the downlink symbol rate and frequency. 

8.1 .5.1 .4 Uplink channel 

Since SSs do not transmit in the uplink channel until they have received some minimal configuration 
information from the BS, it is possible to support several different configurations that can be adjusted on an 
uplink channel basis or on a burst by burst basis. These parameters, and their ranges, are supported through 
MAC signaling, as described in 6.3.2.3.3. 

8.1.5.1.5 Uplink_Burst_Profile 

Each UplinkJ3urst_Profile in the UCD message (6.3.2.3.3) shall include the following parameters: 

— Modulation type 

— FEC Code Type 

— Last codeword length 

— Preamble Length 

— Randomizer Seed 
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If the FEC Code Type is 1, 2, or 3 (RS codes), the Uplink.BurscProfile shall also include 

— RS information bytes (K) 

— RS parity bytes (/?) 

If the FEC Code Type is 2, the Uplink_Burst_Profile shall also include 

— BCC code type 

If the FEC Code Type is 4, the Uplink_Burst_Profile shall also include 

— BTC row code type 

— BTC column code type 

— BTC interleaving type 

Table 162 illustrates the format of the Uplink_Burst_Profile, which is encoded with a Type of 1. 



Table 162— SC Uplink_Burst_Profile format 



Syntax 


Size 


Notes 


Type=l 


8 bits 




Length 


variable 




reserved 


4 bits 


Shall be set to zero i 


UIUC 


4 bits 




TLV encoded information 


variable 


TLV specific 



Within each Uplink_Burst_Profile is an unordered list of PHY attributes, encoded as TLV values (see 
11.3.1). 

8.1.5.2 Uplink Transmission Convergence sublayer 

The uplink Transmission Convergence sublayer operation shall be identical to the downlink Transmission 
Convergence sublayer operation, as described in 8.1 .4.3. 

8.1 .5.3 Uplink PMD sublayer 

The uplink PHY coding and modulation are summarized in the block diagram shown in Figure 155. 

8.1.5.3.1 Randomization for spectrum shaping 

The uplink modulator shall implement a randomizer using the polynomial x 15 + x l 4 + 1. At the beginning of 
each burst, the register is cleared and the Randomizer Seed value 100101010000000 is loaded. The Random- 
izer Seed value shall be used to calculate the randomizer bit, which is combined in an XOR with the first bit 
of data of each burst (which is the MSB of the first symbol following the last symbol of the preamble). 

8.1 .5.3.2 Uplink FEC 

The uplink FEC schemes are as described in 8.1.4.4.4, including Table 146. 
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Figure 155 — Conceptual block diagram of the uplink PHY 



8.1.5.3.2.1 Outer code for Code Types 1-3, uplink 

The Outer Codes for Code Types 1-3 are nearly identical to those of the downlink (8.1.4.4.4.1), with the 
following exceptions: 

a) Fixed Codeword Operation 

In the Fixed Codeword Operation, the number of information bytes in each codeword is always the same 
(K). If the MAC messages in a burst require fewer bytes than are carried by an integral number of Reed- 
Solomon codewords, stuff bytes (FF hex ) shall be added between MAC messages or after the last MAC 
message so that the total message length is an integral multiple of K bytes. 

The SS determines the number of codewords in its uplink burst from the UL-MAP message, which defines 
the beginning point of each burst, and hence the length. The BS determines the number of codewords in the 
received uplink burst as it scheduled this transmission event and is aware about its length. Using the burst 
length, both the SS and the BS calculate the number of full-length RS codewords that can be carried by each 
burst. 

The process used by the SS to encode each burst is identical to the process performed by the BS in Downlink 
Fixed Codeword Operation (8.1 .4.4.4.1). 

b) Shortened Last Codeword Operation 

In the Shortened Last Codeword Operation, the number of information bytes in the final Reed-Solomon 
block of each burst is reduced from the normal number K, while the number of parity bytes R remains the 
same. The BS tailors the number of information bytes in the last codeword, allowing the SS to transport as 
many information bytes as possible in each uplink burst. The BS implicitly communicates the number of 
bytes in the shortened last codeword to the SS via the UL-MAP message, which defines the starting minislot 
of each burst. The SS uses the UL-MAP information to calculate the number of full-length RS codewords 
and the length of the shortened last codeword that can be carried within the specified burst size. This 
calculation shall take into account the number of bytes in the burst used for the preamble and coding bytes as 
well as the guard time. The BS performs a similar calculation as the SS for its decoding purposes. 
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To allow the receiving hardware to decode the previous Reed-Solomon codeword, no Reed-Solomon 
codeword shall have less than 6 information bytes. The number of information bytes carried by the 
shortened last codeword shall be between 6 and K bytes inclusive. In this mode, the BS shall only allocate 
bursts that result in shortened last codewords of the proper length. 

When using Code Type 2, the number of information bytes in the shortened last codeword shall always be an 
even number so that the total codeword size is also an even number. Both BS and SS shall take this into 
account when calculating the number of information bytes in the last codeword. 

The process used by the SS to encode each burst is identical to the process used by the BS in Downlink 
Shortened Last Codeword Operation (8.1.4.4.4.1). 

8.1 .5.3.2.2 Inner code for Code Type 2, uplink 

See 8.1.4.4.4.2. 

8.1 .5.3.2.3 Inner code for Code Type 3, uplink 

See 8.1.4.4.4.3. 



8.1.5.3.2.4 Code Type 4, uplink 

Code Type 4 in the uplink is similar to the downlink case (8.1.4.4.4.4). Some exceptions apply to the uplink 
due to the smaller payload expected within a burst. For example, using a similar two dimensional shortening 
process, a 57-byte code is composed of (32,26) constituent codes which have been shortened by seven rows 
and two columns as described in Figure 156. The end result is a (30,24)x(25,19) array, which is capable of 
encoding 24 x 19 = 456 bits (57 bytes). Table 163 summarizes this code example. 



26 bits 



6 bits 



Unshortened 
Block 



26 bits 



6 bits 



r 




■ 






Data 








Bits 












Shortened 
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ECC Bits 




Block 



Figure 156— Structure of shortened 2 D block 
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Table 163— Required block codes for the BTC option for the uplink channel 



Code 


(30,24)X(25,19) 


Aggregate Code Rate 


0.608 


Uplink/Downlink/Both 


Uplink 


Block size (payload bits) 


456 (57 bytes) 



8.1.5.3.3 Shortening of FEC blocks in uplink 

Shortening of FEC blocks in the uplink is identical to the handling in the downlink as described in 8.1.4.2 or 
8.1.4.4.4.1. 

8.1.5.3.4 Number of scheduled uplink bursts per frame 

Only one scheduled burst (UIUC 4-9) per SS shall be included in the UL-MAP for any given frame. 

8.1 .5.3.5 Coding of the Request IE Uplink_Burst_Profile 

The uplink burst profile associated with the Request IE (UIUC = 1) shall use Modulation Type = 1 (QPSK) 
and shall use FEC Code Type = 1 or 2. The other parameters of the Uplink_Burst_Profile encoding shall be 
chosen such that the resulting uplink burst profile is no less robust than the most robust uplink burst profile 
associated with any of the Data Grant Burst Type IEs. 

8.1.5.3.6 Coding of the Initial Ranging Uplink_Burst_Profile 

The burst profile for the Initial Ranging UIUC shall be the same as for the frame control section, as defined 
in 8.1.4.4.6. 

8.1 .5.3.7 Uplink modulation 

The modulation used on the uplink channel shall be variable and set by the BS. QPSK shall be supported, 
while 16-QAM and 64-QAM are optional, with the mappings of bits to symbols identical to those described 
in 8.1.4.4.7. 

In changing from one burst profile to another, the SS shall use one of two power adjustment rules: 
maintaining constant constellation peak power (power adjustment rule = 0), or maintaining constant 
constellation mean power (power adjustment rule = 1). In the constant peak power scheme, corner points are 
transmitted at equal power levels regardless of modulation type. In the constant mean power scheme, the 
signal is transmitted at equal mean power levels regardless of modulation type. The power adjustment rule is 
configurable through the UCD Channel Encoding parameters (11.3.1). 

In changing from one modulation scheme to another (i.e., during burst profile change), sufficient RF power 
amplifier margins should be maintained to prevent violation of emissions masks. 

8.1.5.3.8 Baseband pulse shaping 

Prior to modulation, the / and Q signals shall be filtered by square-root raised cosine filters as specified in 
8.1.4.4.8. 
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8.1 .5.3.9 Transmitted waveform 

The transmitted waveform shall be as described in 8.1.4.4.9. 
8.1.6 Baud rates and channel bandwidths 

A large amount of spectrum is potentially available in the 10-66 GHz range for PMP systems. Although 
regulatory requirements vary between different regions, sufficient commonality exists for a default RF 
channel bandwidth to be specified for each major region. This is necessary in order to ensure that products 
built to this standard have interoperability over the air interface. 

Systems shall use Nyquist square-root raised cosine pulse shaping with a roll-off factor of 0.25 and shall 
operate on the default RF channel arrangement shown in Table 164. Note that baud rates are chosen to 
provide an integer number of PSs per frame. The frame duration choice compromises between transport 
efficiency (with lower frame overhead) and latency. 



Table 164— Baud rates and channel sizes for a roll-off factor of 0.25 



Channel size 
(MHz) 


Symbol rate 
(MBd) 


Bit rate 
(Mb/s) 
QPSK 


Bit rate 
(Mb/s) 
16-QAM 


Bit rate 
(Mb/s) 
64-QAM 


Recommended . 
Frame Duration 

(ms) 


Number of 
PSs/frame 


20 


16 


32 


64 


96 


1 


4000 


25 


20 


40 


80 


120 


1 


5000 


28 


22.4 


44.8 


89.6 


134.4 


1 


5600 



Due to wide variations in local regulations, no frequency plan is specified in this standard. No single plan 
can accommodate all cases. For example, the 24.5-26.5 GHz band in Europe is regulated by CEPT 
requirements concerning specific duplex spacing and rasters. This does not match a similar spectrum 
allocation in North America. 

8.1.7 Radio subsystem control 

8.1.7.1 Synchronization technique 

The downlink demodulator typically provides an output reference clock that is derived from the downlink 
symbol clock. This reference can then be used by the SS to provide timing for rate critical interfaces when 
the downlink clock is locked to an accurate reference at the BS. 

Accurate uplink time slot synchronization is supported through a ranging calibration procedure defined by 
the MAC to ensure that uplink transmissions by multiple users do not interfere with each other. Therefore, 
the PHY needs to support accurate timing estimates at the BS, and the flexibility to finely modify the timing 
at the SS according to the transmitter characteristics specified in 8.1.8. 

8.1.7.2 Frequency control 

In order to meet more stringent coexistence requirements in place today, the transmitted RF center frequency 
for both the BS and at each SS shall have an accuracy better than ±10*10" 6 . The value shall be guaranteed 
over the complete temperature range and time of operation, i.e., aging for FWA equipment. In order to meet 
this main requirement, the following additional requirements have been derived for both BS and SS. The 
carrier frequency accuracy for the BS shall be better than ±8*10" 6 . Therefore: 
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— The carrier frequency accuracy for the BS shall be ±8*10 . 

— The SS shall be locked in frequency to the BS. 

— The carrier frequency of the SS shall be within ±1 * 10" 6 of that of the BS. 
8.1 .7.3 Power control 

The power control algorithm shall be supported for the uplink channel with both an initial calibration and 
periodic adjustment procedure without loss of data. The BS should be capable of providing accurate power 
measurements of the received burst signal. This value can then be compared against a reference level, and 
the resulting error can be fed back to the SS in a calibration message coming from the MAC. The power 
control algorithm shall be designed to support power attenuation due to distance loss or power fluctuations 
at rates of at most 20 dB/second with depths of at least 40 dB. The exact algorithm implementation is 
vendor-specific. The total power control range consists of both a fixed portion and a portion that is 
automatically controlled by feedback. The power control algorithm shall take into account the interaction of 
the RF power amplifier with different burst profiles. For example, when changing from one burst profile to 
another, margins should be maintained to prevent saturation of the amplifier and to prevent violation of 
emissions masks. 

In support of FPC for SC, the CRABS report [B8] describes results that demonstrate LMDS frequency 
bands experiencing significant fast fading both due to rain and foliage impairments. FPC will also allow the 
decoupling of accurate rain fade margin setting on links and improve resilience. The report presented in 
Sydor [B43], although reporting measurements for the 5 GHz band, indicates fades up to 180dB/s based on 
obstruction from trees. 

8.1.8 Minimum performance 

This subclause details the minimum performance requirements for proper operation of systems in the 
frequency range of 24-32 GHz. The values listed in this subclause apply over the operational environmental 
ranges of the system equipment. 

The philosophy taken in this subclause is to guarantee SS interoperability. Hence, the BS is described only in 
terms of its transmitter (Table 165), while the SS is described in terms of both its transmitter (Table 166) and 
receiver (Table 167). It is expected that BS manufacturers will use SS transmitter performance coupled with 
typical deployment characteristics (cell size, channel loading, near-far users, etc.) to profile their receiver 
equipment emphasizing specific performance issues as they require. 



Table 165— Minimum BS transmitter performance 



Tx symbol timing accuracy 


Peak-to-peak symbol jitter, referenced to the previous symbol zero 
crossing, of the transmitted waveform, shall be less than 0.02 of the 
nominal symbol duration over a period of 2 s. The peak-to-peak 
cumulative phase error, referenced to the first symbol time and with 
any fixed symbol frequency offset factored out, shall be less than 0.04 
of the nominal symbol duration over a period of 0. 1 s. 
The Tx symbol timing shall be accurate to within ±8x10^ (including 
aging and temperature variations). 


Tx RF frequency/accuracy 


10-66 GHz/ ± 8X10"^ (including aging and temperature variations). 


Spectral mask (out of band/block) 


Per relevant local regulation requirements (see 8.1.8.2.2 for more 
details). 


Spurious 


Per relevant local regulatory requirements. 
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Table 165 — Minimum BS transmitter performance (continued) 



Maximum Ramp Up/Ramp Down Time 


8 symbols (2 PSs). 


Modulation accuracy (expressed in EVM, 
as in 8.1.8.2.3) 


12% (QPSK); 6% (16-QAM) (Measured with an Ideal Receiver 
without Equalizer, all transmitter impairments included), and 
10% (QPSK); 3% (16-QAM), 1.5% (64-QAM) (Measured with an 
Ideal Receiver with an Equalizer, linear distortion removed). 

NOTE — Tracking loop bandwidth is assumed to be between 1 % to 
5% optimized per phase noise characteristics. The tracking loop 
bandwidth is defined in the following way. A lowpass filter with 
unity gain at DC and frequency response //(/), has a tracking loop 
(noise) bandwidth (B L ), defined as the integral of | H(f)\ squared from 
0 to the sampling frequency. The output power of white noise passed 
through an ideal brick wall filter of bandwidth B L shall be identical to 
that of white noise passed through any lowpass filter with the same 
tracking loop (noise) bandwidth. 


Table 166— Minimum SS transmitter performance 


Tx Dynamic range 


40 dB. 


Tx RMS Power Level at Maximum Power 
Level setting ror i^roiv 


At least +15 dBm (measured at antenna port). 


Tx power level adjustment steps and 
accuracy 


The SS shall adjust its Tx power level, based on feedback from the 
BS via MAC messaging, in steps of 0.5 dB in a monotonic fashion. 
[This required resolution is due to the small gap in sensitivities 
between different burst profiles (3^ dB typical).] 


Tx symbol timing jitter 


Peak-to-peak symbol jitter, referenced to the previous symbol zero 
crossing, of the transmitted waveform, shall be less than 0.02 of the 
nominal symbol duration over a period of 2 s. The peak-to-peak 
cumulative phase error, referenced to the first symbol time and with 
any fixed symbol frequency offset factored out, shall be less than 0.04 
of the nominal symbol duration over a period of 0. 1 s. 


Symbol clock 


Shall be locked to BS symbol clock. 


Tx burst timing accuracy 


Shall implement corrections to burst timing in steps of up to ±0.5 of a 
symbol with step accuracy of up to ±0.25 of a symbol. 


Tx RF frequency/accuracy 


SS frequency locking to BS carrier required. 

10-66 GHz/ ± IX 10 (including aging and temperature variations). 


Spectral Mask (out of band/block) 


Per relevant local regulation requirements (see 8. 1.8.2.2 for more 
details). 


Maximum Ramp Up/Ramp Down Time 


8 symbols (2 PSs). 


Maximum output noise power spectral den- 
sity when Tx is not transmitting information 


-80 dBm/MHz (measured at antenna port). 


Modulation accuracy (expressed in EVM, 
as in 8.1.8.2.3) 


As specified in Table 165. 
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Table 167— Minimum SS receiver performance 



Bit error rate (BER) performance threshold 


For BER = 1 x 10" 3 : 
QPSK: -94 + 101og 10 (/?) 
16-QAM:-87+ 101og 10 (#) 
64-QAM: -79 + 101ogi 0 (fl) 

ror BhK = 1 X 1U 
QPSK: -90 + 101og 10 (/?) 
16-QAM: -83 + 101og 10 (/?) 
64-QAM: -74 + 101ogi 0 (/?) 

NOTE — Measured uncoded in dBm, where R denotes carrier symbol 
rate in MBd. 

Propagation models of Type 0, 1, or 2 (Table 168) are used. 


Maximum Transition time from Tx to Rx 
and from Rx to Tx 


2 us (TDD) 

20 |is (FDD, half-duplex terminal) 


1st Adjacent Channel Interference 


At BER 10" 3 , for 3 dB degradation: 

C/I = -9 (QPSK), -2 (16-QAM), and +5 (64-QAM) 

At BER 10" 3 , for 1 dB degradation: 

C/l = —5 (QraK), +1 (lo-^AMj, ana +y {0<+-Klf\ivi) 

At BER 10" 6 , for 3 dB degradation: 

C/I = -5 (QPSK), +2 (16-QAM), and +9 (64-QAM) 

At BER MT 6 , for 1 dB degradation: 

C/I = -1 (QPSK), +6 (16-QAM), and +13 (64-QAM) 

NOTE — Measured uncoded, in dB. 


2nd Adjacent Channel Interference 


At BER 10" 3 , for 3 dB degradation: 

C/I = -34 (QPSK), -27 (16-QAM), and -20 (64-QAM) 

At BER 10" 3 , for 1 dB degradation: 

C/I = -30 (QPSK), -22 (16-QAM), and -16 (64-QAM) 

At BER 10" 6 , for 3 dB degradation: 

C/I = -30 (QPSK), -23 (16-QAM), and -16 (64-QAM) 

At BER 10" 6 , for 1 dB degradation: 

C/I = -26 (QPSK), -20 (16-QAM), and -12 (64-QAM) 

NOTE — Measured uncoded, in dB. 



NOTE— The interfering source shall be a continuous signal of the same modulation type as the primary signal. The 
spectral mask of the interfering signal shall depend on local regulatory requirements. 

8.1.8.1 Propagation conditions 

LOS radio propagation conditions between the BS and the SSs are required to achieve high quality and 
availability service. Also, the SSs need highly directional antennas, which minimize the number of 
multipaths and interference from unexpected sources. The intersymbol interference may occur as a 
consequence of multipaths. 
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8.1.8.1.1 Propagation models 

In this subclause, the propagation models referred to in this specification are defined. No further BER 
performance degradation should be expected with all propagation model types. 

The channel model is expressed as follows: 

//(/co) = Ci*exp(-y*co7i) + C 2 *exp(-j*(oT 2 ) + C 3 *exp(-y*co7 3 ) (14) 

Here C\,C 2 , and C3 are the complex tap amplitudes and T\J 2 > anc * ^3 are the tap delays. These parameters 
are provided in Table 168, where R is the channel symbol rate in MBd and the resulting tap delay is in ns. 
For example, if R - 20 MBd, then the resulting Type 2 tap delays will be 0, 20, and 40 ns. 



Table 168 — Propagation models 



Propagation model 


Tap number i 


Tap amplitude C,- 


Tap delay 7, 


TypeO 


1 


1.0 


0 


Typel 


1 


0.995 


0 




2 


0.0995 exp(-y0.75) 


400//? 


Type 2 


1 


0.286 exp(-y 0.75) 


0 




2 


0.953 


400//? 




3 


-0.095 


800//? 



NOTE — Propagation path parameters are valid for R from 15 to 25 MBd. 

Type 0 represents a clear LOS scenario. Type 1 and Type 2 represent typical deployment scenarios with 
weak multipath components, Type 1 having better conditions. 

8.1.8.1.2 Rain fades 

For 10-66 GHz frequencies of operation, the predominant fade mechanism is that resulting from rain 
attenuation. Fade depths are geographically dependent by rain rate region and are also conditioned by both 
frequency of operation and link distance. For a given set of equipment transmission parameters and a 
specified link availability requirement, the rain rate criteria establish the maximum cell radius appropriate to 
system operation. 

An internationally accepted method for computation of rain fade attenuation probability is that defined by 
ITU-R P.530-8 [B34]. As an example, typical 28 GHz equipment parameters result in a maximum cell radius 
of about 3.5 km in ITU rain region K. This criteria applies for a link BER = 10" 6 at a link availability of 
99.995%. Further details on this example system model may be found in IEEE Std 802.16.2-2004. 

Another important issue is the impact of uncorrelated rain fading between an interference transmission link 
and a victim transmission link. Under rain fading conditions, the differential rain fading loss between the 
two transmission paths may have a significant impact on both intrasystem and intersystem link availability. 
At operational frequencies around 28 GHz, the estimated rain cell diameter is approximately 2.4 km 
(ITU-R R452 [B33]). The effect of rain decorrelation may be estimated based on cell sector size and the 
specified frequency reuse plan. 



Copyright ©2004 IEEE. All rights reserved. 



347 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



A significant mitigation technique for the control of both intrasystem and intersystem interference is the 
angular discrimination provided by system antennas. The antenna radiation pattern envelope (RPE) 
discrimination has significance for both clear sky and rain faded propagation conditions. The RPE 
requirements for aggressive intrasystem frequency reuse plans may exceed the RPE requirements for the 
control of inter-system coexistence. Recommended antenna RPE characteristics are described in 
IEEE Std 802.16.2-2001. 

8.1 .8.2 Transmitter characteristics 

Unless stated otherwise, the transmitter requirements are referenced to the transmitter output port and apply 
with the transmitter tuned to any channel. 

8.1.8.2.1 Output power 

In the following subclause, power is defined as the time-averaged power when emitting a signal (excluding 
off-time between bursts), measured over the randomized bits of one transmitted burst. 

The power at which SS or BSs shall operate is specified in the following subclause. 

8.1.8.2.1.1 BS 

A BS shall not produce an effective isotropic radiated power (EIRP) spectral density exceeding either 
+28.5 dBmi/MHz or local regulatory requirements. 

8.1 .8.2.1.2 SS 

An SS shall not produce an EIRP spectral density exceeding either +39.5 dBmi/MHz or local regulatory 
requirements. 

8.1.8.2.2 Emission mask and adjacent channel performance (NFD) 

Transmit parameters shall comply with existing ETSI standards having more stringent requirements, in 
particular: 

— Frequency band 40.5 GHz to 43.5 GHz: EN 301 997-1 

— Frequency band 24.25 GHz to 29.5 GHz: EN 301 213-3 

In the downlink channel, the transmitted spectrum shall not exceed the spectrum mask defined by Table 169, 
which specifies more stringent requirements than System Type C spectrum mask defined in EN 301 213-3. 



Table 169— Downlink spectrum mask at 28MHz channel 



Frequency offset (MHz) 


13 


14 


14.4 


14.8 


22.4 


28 


56 


70 


Relative attenuation (dB) 


0 


-15 


-20 


-28 


-34 


-42 


-52 


-52 



In the uplink channel, the transmitted spectrum shall not exceed the spectrum mask defined by Table 170, 
which is derived from the requirements given by System Type B spectrum mask defined in EN 301 213-3. 

The Net-Filter-Discriminator (NFD) mask, which shall be guaranteed by the system, is defined by 
Tablel71. 
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Frequency offset (MHz) 


11.2 


13.5 


14.5 


22.4 


28 


56 


70 


Relative attenuation (dB) 


0 


-7 


-17 


-32 


-37 


-52 


-52 



Table 171— Downlink and uplink NFD mask 



O^set flVlHz} 


FD - DL (dB) 


FD - III THIN 




35,5 


29 


31,5 


39 


34,5 




AO 


JO, J 


38,5 


45 


41 


42 


46,5 


43 


49 


49 


46,5 


56 


51 


50 


59,5 


51,5 


51 


63 


52 


51,5 


70 


52 


52 


77 


52 


52 


84 


52 


52 



8.1.8.2.3 Modulation accuracy and error vector magnitude (EVM) 

The EVM defines the average constellation error with respect to the farmost constellation point power, as 
illustrated in Figure 157 and defined by the following equation: 



EVM = 



l£(A/ 2 + AG 2 ) 
N 1 

J (15) 



where 

N is the number of symbols in the measurement period and 5 max the maximum constellation 
amplitude. 

The EVM shall be measured over the continuous portion of a burst occupying at least 1/4 of the total 
transmission frame at maximum power settings. 

The required EVM can be estimated from the transmitter implementation margin if the error vector is 
considered noise, which is added to the channel noise. 
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The implementation margin means the excess power needed to keep the C/N constant when going from the 
ideal to the real transmitter. EVM cannot be measured at the antenna connector but should be measured by 
an "ideal" receiver with a certain carrier recovery loop bandwidth specified in percent of the symbol rate. In 
Table 172, the EVM- values for different modulation schemes are specified using parameters relevant to the 
system. 

Based on the values in Table 172 the EVM values shall be the following: 

— EVM 12% and 6% for 4-QAM, 16-QAM respectively when measured by an "ideal" receiver without 
an equalizer with a carrier recovery loop bandwidth of 1% to 5%; and 

— EVM 10%, 3% and 1,5% for 4-QAM, 16-QAM, and 64-QAM respectively when measured by an 
"ideal" receiver with an equalizer with a carrier recovery loop bandwidth of 1% to 5%. 



Measured 
Signal 



Error Vector 



Reference 
Signal 



I 



Figure 157— Illustration of EVM 



The above EVM measured will include the transmit filter accuracy, D/A-converter, modulator imbalances, 
untracked phase noise, and power amplifier (PA) non-linearity. 

Table 172— EVM values vs. modulation scheme 



Modulation 


Tx 

implementation 
margin 


Rx-AWGNC/N 
(dB) 
BER = 10E-6 
4 MAC-PDUs 


Peak-to- 
average 


EVM (%) 
Without 
equalization 


EVM (%) 
With 
equalization 


4-QAM + RS 


0.5 dB 


10 


OdB 


12 


10 


16-QAM + RS 


1.0 dB 


17 


2.55 dB 


6 


3 


64-QAM + RS 


1.5 dB 


23 


3.68 dB 


N/A 


1.5 



8.1 .9 Channel quality measurements 
8.1.9.1 Introduction 

RSSI and CINR signal quality measurements and associated statistics can aid in such processes as BS 
selection/assignment and burst adaptive profile selection. As channel behavior is time- variant, both mean 
and standard deviation are defined. 
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The process by which RSSI measurements are taken does not necessarily require receiver demodulation 
lock; for this reason, RSSI measurements offer reasonably reliable channel strength assessments even at low 
signal levels. On the other hand, although CINR measurements require receiver lock, they provide 
information on the actual operating condition of the receiver, including interference and noise levels, and 
signal strength. 

8.1.9.2 RSSI mean and standard deviation 

When collection of RSSI measurements is mandated by the BS, an SS shall obtain an RSSI measurement 
from the downlink burst preambles. From a succession of RSSI measurements, the SS shall derive and 
update estimates of the mean and the standard deviation of the RSSI, and report them via REP-RSP 
messages. 

Mean and standard deviation statistics shall be reported in units of dBm. To prepare such reports, statistics 
shall be quantized in 1 dB increments, ranging from -40 dBm (encoded 0x53) to -123 dBm (encoded 0x00). 
Values outside this range shall be assigned the closest extreme value within the scale. 

The method used to estimate the RSSI of a single message is left to individual implementation, but the 
relative accuracy of a single signal strength measurement, taken from a single message, shall be ± 2 dB, with 
an absolute accuracy of ± 4 dB. This shall be the case over the entire range of input RSSIs. In addition, the 
range over which these single-message measurements are measured should extend 3 dB on each side beyond 
the -40 dBm to -123 dBm limits for the final averaged statistics that are reported. 

The (linear) mean RSSI statistics (in mW), derived from a multiplicity of single messages, shall be updated 
using Equation (16). 



R[0] k = 0 

mW (16) 

O-ttavg^MS/W-n + o *[*] k>0 



where 

k is the time index for the message (with the initial message being indexed by k = 0, the next 
message by k = 1, etc.), 

R[k] is the RSSI in mW measured during message k, and a avg is an averaging parameter specified by the 
BS. The mean estimate in dBm shall then be derived from Equation (17). 

A W = \0\og({i RSSI [k]) dBm (17) 

RSSI dBm 

To solve for the standard deviation in dB, the expectation-squared statistic shall be updated using Equation 
(18). 



*RSSI [k] " 



2 lRl ° f 2 * = ° 08) 



Apply the result to Equation (19). 

= 51og(|4ss/[*]-fes/W) 2 |) dB (19) 



RSSI dB 
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8.1.9.3 CINR mean and standard deviation 

When CINR measurements are mandated by the BS, an SS shall obtain a CINR measurement from the 
downlink burst preambles. From a succession of these measurements, the SS shall derive and update 
estimates of the mean and the standard deviation of the CINR, and report them via REP-RSP messages. 

Mean and standard deviation statistics for CINR shall be reported in units of dB. To prepare such reports, 
statistics shall be quantized in 1 dB increments, ranging from a minimum of -20 dB (encoded 0x00) to a 
maximum of 40 dB (encoded 0x3C). Values outside this range shall be assigned the closest extreme value 
within the scale. 

The method used to estimate the CINR of a single message is left to individual implementation, but the 
relative and absolute accuracy of a CINR measurement derived from a single message shall be ±1 dB and 
± 2 dB, respectively, for all input CINRs above 0 dB. In addition, the range over which these single-packet 
measurements are measured should extend 3 dB on each side beyond the -20 dB to 40 dB limits for the final 
reported, averaged statistics. 

One possible method to estimate the CINR of a single message is by normalizing the mean-squared residual 
error of detected data symbols (and/or pilot symbols) by the average signal power using Equation (20). 

CINR[k]=^ff./ (20) 
where 

CINR[k] is the (linear) CINR for message k, 
r[k,n] is received symbol n within message k, 

sikyTi] is the corresponding detected or pilot symbol corresponding to received symbol n\ 
N-l 

A[k] = £ \s[k,n]\ 2 (21) 
n = 0 

is the average signal power, which is normally kept constant within a message by action of automatic gain 
control (AGC); and 

N-l 

E[k] = £ \r[k,n]-s[k,n]\ 2 (22) 
n = 0 

The mean CINR statistic (in dB) shall be derived from a multiplicity of single messages using Equation (23). 

{i [k] = l0\og({i CINR [k]) (23) 

CINR dB . 

where 



VcinrW = 



CINR[0] k = 0 

(24) 

( l -%vg^CINRl k -U + %vg CINR W *>0 
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where 

k is the time index for the message (with the initial message being indexed by k = 0, the next 
message by k- l,etc), 

CINR[k] is a linear measurement of CENR (derived by any mechanism that delivers the prescribed 
accuracy) for message k\ and a avg is an averaging parameter specified by the BS. 

To solve for the standard deviation, the expectation-squared statistic shall be updated using Equation (25). 



*CINR [k] " 



\CINR[0]\ 2 k = 0 

(1 - a avg>4w/?^- l] + oc avgl CW/?[A:] | 2 * >0 



(25) 



avg' C/7V/c L J avg 
and the result applied to Equation (26) 



a 

CINR dB 



= 51og(|4 W/? [^]-(AcW/?[*]) 2 |) dB (26) 
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8.2 WirelessMAN-SCa PHY 

The WirelessMAN-SCa PHY is based on single-carrier technology and designed for NLOS operation in 
frequency bands below 11 GHz (per 1.3.4). For licensed bands, channel bandwidths allowed shall be limited 
to the regulatory provisioned bandwidth divided by any power of 2 no less than L25 MHz. 

Elements within this PHY include the following: 

— TDD and FDD definitions, one of which must be supported. 

— TDMA uplink. 

— TDM or TDMA downlink. 

— Block adaptive modulation and FEC coding for both uplink and downlink. 

— Framing structures that enable improved equalization and channel estimation performance over 
NLOS and extended delay spread environments. 

— PS-unit granularity in burst sizes. 

— Concatenated FEC using Reed-Solomon and pragmatic trellis coded modulation (TCM) with 
optional interleaving. 

— Additional BTC and CTC FEC options. 

— No-FEC option using ARQ for error control. 

— Space time coding (STC) transmit diversity option. 

— Robust modes for low CINR operation. 

— Parameter settings and MAC/PHY messages that facilitate optional AAS implementations. 

Within the discussion of the WirelessMAN-SCa PHY, five terms (payload, burst, burst set, burst frame, and 
MAC frame) are used in discussion of the organization of transmissions. 

Payload refers to individual units of transmission content that are of interest to some entity at the receiver. 

A burst contains payload data and is formed according to the rules specified by the burst profile associated 
with the burst. The existence of the burst is made known to the receiver through the contents of either the 
uplink or downlink maps. For the uplink, a burst is a complete unit of transmission that includes a leading 
preamble, encoded payload, and trailing termination sequence. 

A burst set is a self-contained transmission entity consisting of a preamble, one or more concatenated bursts, 
and a trailing termination sequence. For the uplink, burst set is synonymous with burst. 

A burst frame contains all information included in a single transmission. It consists of one or more burst sets. 

A MAC frame refers to the fixed bandwidth intervals reserved for data exchange. For TDD, a MAC frame 
consists of one downlink and one uplink subframe, delimited by the TTG. For FDD, the MAC frame 
corresponds to the maximum length of the downlink subframe. FDD uplink subframes operate concurrently 
with downlink subframes but on a separate (frequency) channel. 

The downlink and uplink subframes each hold a burst frame. 
8.2.1 Transmit processing 

Figure 158 illustrates the steps involved in transmit processing. Source data shall first be randomized; then 
FEC encoded and mapped to QAM symbols. QAM symbols shall be framed within a burst set, which 
typically introduces additional framing symbols. Symbols within a burst set shall be multiplexed into a 
duplex frame, which may contain multiple bursts. The / and Q symbol components shall be injected into 
pulse shaping filters, quadrature modulated up to a carrier frequency, and amplified with power control so 
that the proper output power is transmitted. 
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Except where indicated otherwise, transmit processing is the same for both the uplink and downlink. 

Carrier 

burst set 

framed dup i ex framed 



randomized 
bits 



source 
bits 



randomiza- 
tion 



FEC and 
QAM con- 
stellation 
mapping 



QAM 
symbols 



symbols 



symbols 




Tx — 
Filtering 



Frequency 



Tx 
Filtering 



Quadrature 
Modulation 



transmit 
signal 



Power 
Control 



Figure 158— Transmit processing 



8.2.1.1 Source Bit Randomization 

Source bits, i.e., the original information bits prior to FEC encoding, shall be randomized during 
transmission. 



preset / reset register contents 
1 0 0 1 0 1 0 1 0 0 0 0 0 0 0 
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12 
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14 
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data in 




Figure 159— Randomizer for energy dispersal 



As Figure 159 illustrates, source bit randomization shall be performed by modulo-2 addition (XORing) 
source (information) data with the output of a Linear-Feedback Shift Register (LFSR) possessing 
characteristic polynomial 1 + X 14 + X 15 . The LFSR shall be preset at the beginning of each burst set (directly 
following the preamble) to the value 100101010000000, and shall be clocked once per processed bit. The 
LFSR is not preset between time division multiplexed allocations that may reside within a single burst. 

Only source bits are randomized. This includes source payloads, plus uncoded null (zero) bits that may be 
used to fill empty payload segments. Elements that are not a part of the source data, such as framing 
elements and pilot symbols shall not be randomized. Null (zero) bits used to complete a QAM symbol (when 
an allocation does not fill an entire QAM symbol) shall not be randomized. 

8.2.1.2 FEC 

FCH payloads shall be encoded in accordance with 8.2.1.7. Adaptive modulation and the concatenated FEC 
of 8.2.1.2.1 shall be supported for all other payloads. The support of 8.2.1.2.3 as FEC as well as omitting the 
FEC and relying solely on ARQ for error control (see 8.2.1.2.2) is optional for payloads carried outside the 
FCH. 
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8.2.1.2.1 Concatenated FEC 

The concatenated FEC is based on the serial concatenation of a Reed-Solomon outer code and a rate- 
compatible TCM inner code. Block interleaving between the outer and inner encoders is optional. Figure 
160 illustrates the flow between blocks used by a concatenated FEC encoder. 



Outer Encoder 
RS(M*,7) 



Figure 160— Concatenated FEC encoder blocks 



8.2.1.2.1.1 Outer code 

The outer code consists of a Reed-Solomon code. 

This Reed-Solomon code shall be derived from a systematic RS (N = 255, K = 239) code using GF(2 8 ). The 
following polynomials are used for the systematic code: 

Code Generator Polynomial: g(x) = (x + X°)(x + X i )(x + \ 2 )...(x + \ 2T ~ l ) t \ = 02 HEX 

Field Generator Polynomial: p(x) = x* + x* + x 2 + x 2 + l 

The bit/byte conversion shall be MSB first. 

This RS code may be shortened and punctured to enable variable block sizes and variable error-correction 
capability, 

where 

AT is the number of overall bytes after encoding, 

K is the number of data bytes before encoding, 

R = N-K is the number of parity bytes. 

When a block is shortened to tf'data bytes, the first 239-K' data bytes of the block to be encoded shall be set 
to zero, but shall not be transmitted. When a codeword is punctured to /?' parity bytes, only the first R' of the 
total R = 16 parity bytes shall be transmitted. 

Support of shortening K of the base code to values smaller than 239 bytes while maintaining R = 16 is 
mandatory, and is governed by the burst profile specification for K (see 11.3.1.1 or 11.4.2). The capability to 
also puncture, such that R < 16, is mandatory, and is governed by the burst profile specification for R. 
However, payloads that cannot be modified by burst profile changes, such as the contents of the FCH, shall 
not be punctured. 

When a source allocation does not divide into an integer number of K byte Reed-Solomon code words, the 
last (fractional) RS code word shall be shortened to a smaller value 1 < K< K that accommodates the 
remainder bytes. All code words, including the shortened last codeword, shall use the R specified by the 
burst profile (see Table 354 and Table 360) for the RS code words within that allocation. 



Byte 
Interleaver 
(optional) 



Inner Encoder 
Rate-compatible 
TCM from K=l 
rate 1/2 CC Code 
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8.2.1 .2.1 .2 Block Interleaver 

Support of interleaving between the inner and outer code with a depth ofN R = 10 is mandatory. Interleaving 
shall not be defined in the FCH burst profile. When interleaving is used, its usage and parameters shall be 
specified within a burst profile. 

The interleaver changes the order of bytes from the Reed-Solomon (RS) encoder output. A de-interleaver in 
the receiver restores the order of the bytes prior to RS decoding. The interleaver is a block interleaver, where 
a table is "written," i.e., filled, a byte at a time row-wise (one row per RS code word) and "read" a byte at a 
time column- wise. The number of rows, N R , used by the interleaver is a burst parameter. So. that bursts are 
not generated that exceed an intended receiver's capabilities, the largest N R supported by a terminal is 
communicated during SS basic capability negotiation. 



Operating parameters for the interleaver are summarized in Table 173. 

Table 173— Operating parameters for block interleaver 



Parameter 


Description 


C 


Interleaver Width (number of columns), in bytes. Equivalent to the nominal Reed-Solomon 
codeword length, N. 




Maximum Interleaver Depth (number of rows), in bytes. Equals the maximum number of RS 
codewords that the block interleaver may store at any given time. 


B 


Nominal Interleaver Block Size, in bytes. B = C N R . 


P 


RS-encoded Size of Packet, in bytes, to be interleaved. 



When P < B and/or a RS codeword is shortened (so that not all of the columns within its row are filled), the 
interleaver shall be read column by column (taking a byte from each column), skipping empty elements 
within the table. 



When P > B, data shall be parcelled into subblocks, and interleaving performed within each of the sub- 
blocks. The depth of these subblocks shall be chosen such that all subblocks have approximately the same 
depth (number of rows) using the following calculations: 

Total RS codewords in packet: T = 

Number of subblocks: S = |~^~| 

Interleaver depth of longest subblocks: C max = 

Number of blocks with depth C max : Q Cm = T- S(C max - 1) 

Number of blocks with depth C min = C max - 1 : Q CaiH = S - Qc max 

The first <2 C _ subblocks within a packet shall use a (dynamic) interleaver depth C max , and the remainder of 
the subblocks shall use an interleaver depth C min = C max - 1 . 

8.2.1.2.1.3 Inner code 

The inner code is a rate-compatible pragmatic TCM code (Viterbi, et al [B46], Wolf and Zehavi [B47]) 
derived from a rate 1/2 constraint length K=l, binary convolutional code. 
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The encoder for the rate 1/2 binary code shall use the following polynomials [Equation (27)]to generate its 
two code bit outputs, denoted X and Y: 

G i = m ocr For x 

G 2 = 133 ocr For Y ^ 



A binary encoder that implements this rate 1/2 code is depicted in Figure 161. 




To generate binary code rates of 2/3, 3/4, 5/6, and 7/8, the rate 1/2 encoder outputs shall be punctured. The 
puncturing patterns and serialization order for the X and Y outputs are defined in Tabie 174. In the puncture 
patterns, a "1" denotes a transmitted output bit and a " 0" denotes a nontransmitted (punctured) bit. 



Table 174— Puncture patterns and serialization for convolution code 





Code rates 


Rate 


1/2 


2/3 


3/4 


5/6 


7/8 


X Output 
Puncture pattern 


1 


10 


101 


10101 


1000101 


Y Output 
Puncture pattern 


1 


11 


110 


11010 


1111010 


Punctured XY 
serialization 


X i Y l 


X { Y { Y 2 


X 1 Y 1 Y 2 X 3 


X 1 Y 1 Y 2 X 3 Y 4 X 5 


X 1 Y 1 Y 2 Y 3 Y 4 X 5 Y 6 X 7 



A pragmatic TCM code is constructed from both nonsystematic coded bits (that are taken from the outputs 
of the punctured rate 1/2 binary convolutional encoder) and systematic uncoded bits (that are taken directly 
from the encoder input). The resulting coded bits are then mapped to symbol constellations. Supported 
modulations and code rates for uplink and downlink transmissions are listed in Table 175. The choice of a 
particular code rate and modulation is made via burst profile parameters 
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Since the RS outer code generates byte-denominated records but the inner code generates symbol- 
denominated outputs, some RS record sizes could require a fractional QAM symbol at the end of the data 
record. When this occurs, sufficient (nonrandomized) zero-valued (null) bits shall be appended to the end of 
the inner encoder's input record to complete the final symbol. A receiver shall discard these null bits after 
inner decoding. 

Table 175— Supported modulations and inner (TCM) code rates 



Modulation 


Support 
(M = Mandatory, O = Optional) 


Inner code rates 


Bits/symbol 


UL 


DL 


Spread BPSK 


M 


M 


(pre-spread) 
1/2, 3/4 


(post-spread) 
l/(2*Fs), 3/(4*Fs) 


BPSK 


M 


M 


1/2, 3/4 


1/2, 3/4 


QPSK 


M 


M 


1/2, 2/3, 3/4, 5/6, 7/8 


1, 4/3, 3/2, 5/3, 7/4 


16-QAM 


M 


M 


1/2, 3/4 


2,3 


64-QAM 


M 


M 


2/3, 5/6 


4,5 


256-QAM 


0 


0 


3/4, 7/8 


6,7 



Inner code blocks are to be zero-state terminated in transitions between adaptive modulation (and FEC) 
types, at the ends of bursts, or as instructed by the MAC and frame control. 

When using zero state termination, the baseline rate 1/2 convolutional encoder shall be initialized with its 
registers in the all-zeros state. Inner encoding shall begin from this state, by accepting bit inputs. To 
terminate the inner code (and return the encoder to the all-zeros state) at the end of a code block, at least six 
zero inputs shall be fed into the baseline rate 1/2 binary convolutional encoder to ensure its register memory 
is flushed, i.e., its state memory is driven to zero. Once the first flushing zero bit is introduced into the 
convolutional encoder memory, all input bits, including the systematic input bits that are parallel to the 
binary convolutional encoder inputs, shall have zero value. 

Table 176 specifies the exact number of systematic and nonsystematic bits that shall be used to flush a 
pragmatic TCM encoder for a given modulation and code rate. It also tabulates the number of symbols 
consumed in the code termination process. Spread BPSK with a spreading factor of Fs consumes Fs-times 
more symbols than BPSK. 

Table 176 — Flushing bit requirements for inner code termination 



Modulation 


Inner 
code 
rate 


Number of flushing bits 


Number of 
consumed 
symbols 


Nonsystematic 


Systematic 


Total 


spread 
BPSK 


1/2 


(pre-spread) 
6 


(pre-spread) 
0 


(pre-spread) 
6 


(post-spread) 1 
12*Fs | 




3/4 


(pre-spread) 
6 


(pre-spread) 
0 


(pre-spread) 
6 


(post-spread) 
8*Fs 


BPSK 


1/2 


6 


0 


6 


12 




3/4 


6 


0 


6 


8 
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Table 176 — Flushing bit requirements for inner code termination (continued) 



Modulation 


Inner 
code 
rate 


Number of flushing bits 


Number of 
consumed 
symbols 


Nonsystematic 


Systematic 


Total 


QPSK 


1/2 


6 


0 


6 


6 [ 




2J3 


7 


0 


7 


5 




3/4 


6 


0- 


6 


4 




5/6 


6 


0 


6 


4 




7/8 


7 


0 


7 


4 


16-QAM 


1/2 


6 


0 


6 


3 




3/4 


6 


12 


18 


6 


64-QAM 


2/3 


6 


6 


12 


3 




5/6 


6 


4 


10 


2- 


256-QAM 


3/4 


6 


12 


18 


3 




7/8 


6 


8 


14 


2 



— Encoding for spread BPSK, all rates 

See 8.2.1.3.2. 

— Encoding for BPSK and QPSK modulations, all rates 

For BPSK, the binary outputs of the punctured binary encoder shall be directly sent to the BPSK 
symbol mapper, using the multiplexed output sequence shown in the "XF'-headed row of Table 174. 
For QPSK, the multiplexed output sequence in Table 174 is alternately assigned to the / and Q 
coordinate QPSK mapper, with the I coordinate receiving the first assignment. 
Subclause 8.2.1.3.1 describes the constellation mapping procedure and Figure 170 and Figure 171 
depict bits-to-symbol-constellation maps that shall be used for BPSK and QPSK, respectively. 

— Encoding for rate 1/2 16-QAM 

Figure 162 illustrates the rate 1/2 pragmatic TCM encoder for 16-QAM. The baseline rate 1/2 binary 
convolutional encoder first generates a 2-bit constellation index, b 3 b 2 , associated with the / symbol 
coordinate. Provided the next encoder input, it generates a two-bit constellation index, b { b 0 , for the 
Q symbol coordinate. The / index generation shall precede the Q index generation. Note that this 
encoder should be interpreted as a rate 2/4 encoder, because it generates one 4-bit code symbol per 
two input bits. For this reason, input records of lengths divisible by two shall be fed to this encoder. 
Figure 171 depicts the bits-to-constellation map that shall be applied to the rate 1/2 16-QAM 
encoder output. This is a Gray code map. 
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Figure 1 62— Pragmatic TCM encoder for rate 1/2 16-QAM 



— Encoding for rate 3/4 16-QAM 

Figure 163 illustrates the rate 3/4 pragmatic TCM encoder for 16-QAM. This encoder uses the 
baseline rate 1/2 binary convolutional encoder, along with two systematic bits that are passed 
directly from the encoder input to the encoder output. With this structure, the encoder is capable of 
simultaneously generating four output bits per three input bits. The sequence of arrival for the 
« 2 "i"o input into the encoder is u 2 arrives first, u x second, u 0 last. During the encoding process, the 
encoder generates a two-bit constellation index, b 3 b 2 , for the / symbol coordinate, and 
simultaneously generates another two-bit constellation index, designated b x b 0 , for the Q symbol 
coordinate. Note that whole symbols shall be transmitted, so input records of lengths divisible by 
three shall be fed to this encoder. 

Figure 174 depicts the bits-to-symbol-constellation map that shall be applied to the rate 3/4 16- 
QAM encoder output. This is pragmatic TCM map. 
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Figure 163— Pragmatic TCM encoder for rate 3/4 16-QAM 



— Encoding for rate 2/3 64-QAM 

Figure 164 illustrates the rate 2/3 pragmatic TCM encoder for 64-QAM. This encoder uses the 
baseline rate 1/2 binary convolutional encoder, along with one systematic bit that is passed directly 
from the encoder input to the encoder output. The sequence of arrival for the u x u$ input into the 
encoder is u { arrives first, u 0 last. The encoder (as a whole) then generates a 3-bit constellation 
index, b 5 b A b^ which is associated with the / symbol coordinate. Provided another 2-bit encoder 
input, the encoder generates another 3-bit constellation index, b 2 b x b 0 , which is associated with the Q 
symbol coordinate. The / index generation should precede the Q index generation. Note that this 
encoder should be interpreted as a rate 4/6 encoder, because it generates one 6-bit code symbol per 
four input bits. For this reason, input records of lengths divisible by four shall be fed to this encoder. 
Figure 174 depicts the bits-to-symbol-constellation map that shall be applied to the rate 2/3 
64-QAM encoder output. This is a pragmatic TCM map. 
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/, or Q output sequence: 
(*» Qh k+\> Qk+b - 



Figure 164— Pragmatic TCM encoder for rate 2/3 64-QAM 



— Encoding for rate 5/6 64-QAM 

Figure 165 illustrates the rate 5/6 pragmatic TCM encoder for 64-QAM. This encoder uses a rate 
3/4 punctured version of the rate baseline rate 1/2 binary convolutional encoder, along with two 
systematic bits that are passed directly from the encoder input to the encoder output. The rate 3/4 
punctured code is generated from the baseline rate 1/2 code using the rate 3/4 puncture mask 
definition in Table 174. Puncture samples are sequenced c 3 first, c 2 second, cj third, and c 0 last. The 
sequence of arrival for the u 4 u^u 2 uiu 0 input into the encoder is w 4 arrives first, w 3 arrives second, u 2 
arrives third, u { arrives next to last, and u 0 arrives last. During the encoding process, the pragmatic 
encoder generates a 3-bit constellation index, b 5 b 4 b 3 , for the / symbol coordinate, and 
simultaneously generates another 3-bit constellation index, b 2 bib 0 , for the Q symbol coordinate. 
Note that whole symbols shall be transmitted, so input records of lengths divisible by five shall be 
fed to this encoder. 

Figure 174 depicts the bits-to- symbol-constellation map that shall be applied to the rate 5/6 64- 
QAM encoder output. This is a pragmatic TCM map. 
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Figure 165— Pragmatic TCM encoder for rate 5/6 64-QAM 



Encoding for rate 3/4 256-QAM 

Figure 166 illustrates the rate 3/4 pragmatic TCM encoder for 256-QAM. This encoder uses the 
baseline rate 1/2 binary convolutional encoder, along with two systematic bits that are passed 
directly from the encoder input to the encoder output. The sequence of arrival for the u 2 u\Uq input 
into the encoder is u 2 arrives first, u x next, w 0 last. Note that the encoder (as a whole) first generates 
a 4-bit constellation index, b^b 6 b 5 b 4 , which is associated with the / symbol coordinate. Provided 
another 4-bit encoder input, it generates a 4-bit constellation index, b 3 b 2 bib 0 , which is associated 
with the Q symbol coordinate. The / index generation should precede the Q index generation. Note 
that this encoder should be interpreted as a rate 6/8 encoder, because it generates one 8-bit code 
symbol per 6 input bits. For this reason, input records of lengths divisible by 6 shall be fed to this 
encoder. 

Figure 166 depicts the bits-to-symbol-constellation map that shall be applied to the rate 3/4 256- 
QAM encoder output. This is a pragmatic TCM map. 
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Figure 166— Optional pragmatic TCM encoder for rate 3/4 256-QAM 



Encoding for rate 7/8 256-QAM 

Figure 167 illustrates the rate 7/8 pragmatic TCM encoder for 256-QAM. This encoder uses a rate 
3/4 punctured version of the rate baseline rate 1/2 binary convolutional encoder, along with two 
systematic bits that are passed directly from the encoder input to the encoder output. The rate 3/4 
punctured code is generated from the baseline rate 1/2 code using the rate 3/4 puncture mask 
definition in Table 174. Puncture samples are sequenced c 3 first, c 2 second, c x third, and c 0 last. The 
sequence of arrival for the u 6 u 5 u 4 u 3 u 2 u x u 0 input into the encoder (as a whole) is u 6 arrives first, u 5 
arrives second, w 4 arrives third, u 3 arrives fourth, u 2 arrives fifth, u x arrives next to last, and uq 
arrives last. During the encoding process, the encoder generates a 4-bit constellation index, b 7 b 6 b 5 b 4 , 
for the / symbol coordinate, and simultaneously generates another 4-bit constellation index, 
b 3 b 2 b l b 0 , for the Q symbol coordinate. Note that whole 256-QAM symbols should be transmitted, 
so input records of lengths divisible by seven shall be fed to this encoder. 

Figure 167 depicts the bits-to-symbol-constellation map that shall be applied to the rate 7/8 
256-QAM encoder output. This is a pragmatic TCM map. 
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Figure 167— Optional pragmatic TCM encoder for rate 7/8 256-QAM 



8.2.1.2.2 No FEC 

In the No FEC option, randomized source data shall be mapped directly to a QAM symbol constellation, 
using the appropriate Gray coding map. These maps are found in Figure 170 (for BPSK), Figure 171 (for 
QPSK, 16-QAM), Figure 172 (for 64-QAM), and Figure 173 (for 256-QAM). No-FEC operation is 
mandatory for QPSK but optional for other modulation. 

In the event that the source record size in bytes does not divide into an integral number of QAM symbols, 
sufficient derandomized zero-valued (null) bits shall be appended to the end of the data record to complete 
the last symbol. These null bits shall be discarded at the receiver. 
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8.2.1.2.3 BTCs 



Support of the BTC FEC is optional 



A BTC is formed from block row codes, each with rate parameters (n x , k x ) and block column codes, each 
with rate parameters (n y ky). The BTC is encoded by writing data bits row by row into a two-dimensional 
matrix as illustrated in Figure 168. The k x information bits in each row are encoded into n x bits by using a 
constituent block (n x , k x ) row code. The k y information bits in each column are encoded into n y bits by using 
a constituent block (n y k y ) column code, where the checkbits of the rows are also encoded. The resulting 
BTC shall have block length n = n x xn y bits and information length k = k x x ky . 
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Figure 168— BTC and shortened BTC structures 



The constituent row code and constituent column code used to form the rows and columns of a BTC shall be 
specified by BTC-specific burst profile parameters. The constituent codes available for specification are 
listed in Table 177. All codes in Table 177 shall be formed by appending a check bit or check bits to the end 
of the information bits. A parity check code shall use one check bit, derived by XORing the information bits. 

An extended Hamming component code shall use n-k check bits. The first n-k-1 check bits are the check 
bits of a (n-1, k) Hamming code derived from one of the generator polynomials listed in Table 178, while 
the last check bit is a parity check bit, derived by XORing the n-1 information and parity bits of the k) 
Hamming code. 



Table 177— BTC component codes 



Component codes (n, k) 


Code type 


(64,57), (32,26), (16,11), (8,4) 


Extended Hamming Code 


(64,63), (32,31), (16,15), (8,7) 


Parity Check Code 
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Table 178— (n-1, fc) Hamming code generator polynomials 



n-l 


k 


Generator polynomial 


7 


4 


X 3 +X*+l 


15 . 


11 




31 


26 


X 5 +X 2 +l 


63 


57 


X^X+l 



To match an arbitrary required packet size, BTCs may be shortened by removing symbols from the BTC 
array. Rows, columns, or parts thereof can be removed until the appropriate size is reached. The following 
two steps, illustrated in Figure 168, are involved in the shortening of product codes: 

Step 1) Remove I x rows and I y columns from the two-dimensional code. This is equivalent to 

shortening the constituent codes that make up the product code. 
Step 2) Remove B individual bits from the first row of the two-dimensional code starting with the 

LSB. 

The resulted block length of the code is (n x - I x )(n y - I y ) - B. The corresponding information length is given 
as (k x -l x )(k y - Iy) - B. Consequently, the code rate is given by Equation (28). 

(k x -I x ){k y -I y )-B (28) 
(n x -I x )(n y -I y )-B 

Data bit ordering for the composite BTC matrix is defined such that the leftmost bit in the first row is the 
LSB. The next bit in the first row is the next-to-LSB. The last data bit in the last data row is MSB. An 
encoded BTC block shall be read out of the encoded matrix (for transmission) as a serial bit stream, starting 
with the LSB and ending with the MSB. This bit stream shall be sent to a symbol mapper, which uses a Gray 
map, depicted in Figure 170 for BPSK, Figure 171 for QPSK, 16-QAM, and the Gray maps depicted in 
Figure 172 and Figure 173 for 64-QAM, and 256-QAM. If not enough encoded bits are available to fill the 
last symbol of an allocation, sufficient zero- valued bits (derandomized) shall be appended to the end of the 
serial stream to complete the symbol. 

Two independent variables, C bank and K, collectively specify the BTC encoding and shortening process. 
c bank is a burst profile parameter specified by the MAC. Its values range from 1 to 3, where each integer 
refers to a unique set of constituent codes, chosen to set the code rate of the BTC. K is the desired 
information block length, in bits, to be transmitted within an allocation. Table 179 specifies three code 
selection banks, each containing four different base BTCs, covering a range of information and encoded data 
block lengths. Each base BTC is composed from the specified row and column codes. The code selection 
bank that most closely matches the desired performance should be chosen as the active code bank. 
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Table 179— BTC code banks 





Component row code 
(n#k x ) bits 


Component column code 
(n y k y ) bits 


Base BTC block 
(n^ipkfix) bits 


R = 0.94 


(64,63) 


(64,63) 


(4096,3969) 


(32,31) 


(32,31) 


(1024,961) 


(16,15) 


(16,15) 


(256,225) 


(8,7) 


. (8,7) 


(64,49) 


C bank =2 
RbOW 


(64,63) 


(64,57) 


(4096,3591) 


. (32,31) 


(32,26) 


(1024,806) 


(16,15) 


(16,11) 


(256,165) 


(8,7) 


(8,4) 


(64,28) 


C bankr3 
R = 0.69 


(64,57) 


(64,57) 


(4096,3249) 


(32,26) 


(32,26) 


(1024,676) 


(16,11) 


(16,11) 


(256,121) 


(8,4) 


(8,4) 


(64,16) 



From the selected C banh a corresponding row and column constituent code shall be chosen that best matches 
the total number of information bits, K, to be encoded. Then the result shall be shortened to the exact 
information block size. The procedure for doing so shall be as follows: 

Step 1: Determine the row and column component codes. 

Select the base BTC with the smallest k x xky, such that K < k x x ky . If K exceeds the largest 
information block length available in the code selection bank, the K information bits shall be split 
across A^iocks = cei 1(^/(8 * maxInfoBlock)), where maxInfoBIock is the number of information 
bytes in the largest BTC in the code selection bank. The first A^ b j ocks - 1 blocks shall encode cei\(K/ 
S^blocks) bytes. The final block shall encode the remaining (K/8) - (^blocks ~ l)* ce iK^8/N blocks ) 
bytes. Each of the Af blocks blocks is encoded according to Step 2, substituting for K the number of 
information bits assigned to that block. Shortening of the BTC may be required for all blocks 
blocks. The code selection bank shall remain unchanged for the duration of the blocks- 

Step 2: Determine the row and column component codes for remnant bits 

Select the base BTC with the smallest k x xky such that K<k x xk y . . 

Should K be equal to k^ky, then K fits exactly into the base BTC and the information bits are 
encoded without shortening. If this is not the case, then the (nyXn^kyXk^ BTC shall be shortened 
according to Step 3 after which the K bits are encoded. 

Step 3: Determine shortening parameters 

Select i such that: 
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«E[nd. ((* x -[i*lJ) - (*>-[|J) >°] <></<2* y -l (29) 

The obtained i specifies the shortening parameters: l x = l)/2j, = L«/2j , and 
B = {k x -I x )x(k y -I y )-K. 

8.2.1 .2.4 Convolutional Turbo Codes 

Support of the Convolutional Turbo Code FEC is optional. 
8.2.1.2.4.1 CTC encoder 

The Convolutional Turbo Code encoder, including its constituent encoder, is depicted in Figure 169. It uses 
a double binary Circular Recursive Systematic Convolutional code. The bits of the data to be encoded are 
alternately fed to inputs A and B, starting with the MSB of the first byte being fed to A. The encoder is fed by 
blocks of k bits or N couples (k = 2xN bits). For all frame sizes, k is a multiple of 8 and N is a multiple of 4. 
Furthermore N shall be limited to: 8 < N/4< 256. Zero padding should be used for block sizes less than 32 
bytes. For allocations longer than 256 bytes (i.e., 512 nibbles), the allocation (in units of nibbles), A n 
determines the number of interleaver code blocks, n B , that shall be transmitted. The first n F of these blocks 
shall each use an interleaver of length N F nibbles, whereas the remainder shall each use an interleaver of 
length N F + 1 nibbles as defined in Equation 26. 



*•&] 

n F = n B {N F +l) ~ A n 

The polynomials defining encoder the connections are described in hexadecimal and binary symbol 
notations as follows: 

— For the feedback branch: OxB, equivalently 1 + D + D 3 (in binary symbolic notation) 

— For the Y parity bit: OxD, equivalently 1 + D 2 + D 3 




Constituent encoder 



Figure 169— CTC encoder 
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First, the encoder (after initialization by the circulation state Sc h see 8.2.1.2.4.2) is fed the sequence in the 
natural order (position 1) with the incremental address i = 0,...,AM. This first encoding is called C v 
encoding. Then the encoder (after initialization by the circulation state 5c 2 , see in subclause 8.2.1.2.4.2) is 
fed by the interleaved sequence (switch in position 2) with incremental address j = 0,...,AM. This second 
encoding is called C 2 encoding. 

8.2.1.2.4.2 CTC interleaver 

The interleaver requires the parameters P 0 , which shall be the nearest prime number greater than JWn , with 
P 0 z 3 , which is dependent on the block size N. The two-step interleaver shall be performed by: 

Step 1: Switch alternate couples 

for j = 1...JV 

if Omod 2 ==°) let (BA) = (AJB) (i.e. switch the couple) 
Step 2: !>,•(/) 

The function P£j) provides the interleaved address i of the consider couple j. 
for j = 1...N 

switch 7mod4 : 

case0orl:i = (P 0 . 7 + i )modw 
. case 2 or 3: i = <p 0 j + i +^/4) mod ^ 

8.2.1.2.4.3 Determination of CTC circulation states 

The state of the encoder is denoted 5 (0 < S < 1) with S the value read binary (left to right) out of the 
constituent encoder memory (see Figure 169). The circulation states Sc x and Sc 2 are determined by the 
following operations: 

Step 1) Initialize the encoder with state 0. Encode the sequence in the natural order for the 
determination of Sc { or in the interleaved order for determination of Sc 2 . ^ t> otn cases, the 
final state of the encoder is 50^; 

Step 2) According to the length N of the sequence, use Table 180 to find Sc x or Sc 2 . 



Table 180— Circulation state lookup table (Sc) 



^mod 7 
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4 
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0 
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0 


2 


5 
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6 


6 


0 


7 


6 


1 


3 


4 


5 


2 
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8.2.1.2.4.4 CTC puncturing 

The various code-rates are achieved through selectively deleting the parity bits (puncturing). The puncturing 
patterns are identical for both codes C\ and C 2 . 



Table 181— Circulation state lookup table (Sc) 



Rate 


Y 




0 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


1/2 




1 






























2/3 




0 


1 


0 


























3/4 




0 


0 


1 


0 


0 






















5/6 




0 


0 


0 


0 


1 


0 


0 


0 


0 














7/8 




0 


0 


0 


0 


0 


0 


1 


0 


0 


0 


0 


0 


0 


0 


0 



8.2.1.2.4.5 CTC modulation mapping 

The encoded bit is fed into the mapper for BPSK and QPSK in the following order: 
A 0 , B 0 ..A N _ h B N _ { , y 10 , i y 1M , Y 2 q, Y 2l Y 2 j4, 

where M is the number of parity bits and the / channel is fed first. The order in which the encoded bit are fed 
into the mapper for 16-QAM, 64-QAM and 265-QAM is: 

A 0> B 0 A/to B Rn , y 10 , A Rn+h B Rn+2 A^, B 2Rni Y 2 0 

Let S be half the number of bits in the modulation symbol. Then if (R n +l) equals S, the parity bits are mapped 
to the two least protected locations in the constellation (16-QAM = {b 0 ,b 2 ], 64-QAM ={b 0 ,b 3 ], 256-QAM 
= {b 0 , fc 4 }). If (R n +l) equals 25, the parity bits are mapped to the least protected bit in the modulation scheme 
in the Q channel, using the mapping specified in the mandatory mode (b 0 for 16-QAM, 64-QAM and 256- 
QAM). 

8.2.1.3 Modulations and constellation mapping 

Table 182 lists supported modulations. 

Table 182— Modulations supported 



Modulation 


Support 
(M=Mandatory, 0=Optional) 


UL 


DL 


Spread BPSK 


M 


M 


BPSK 


M 


M 


QPSK 


M 


M 


16-QAM 


M 


M 


64-QAM 


M 


M 


256-QAM 


0 


0 
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With the exception of spread-BPSK, FEC-encoded bits are mapped directly to a modulation constellation 
using one of the constellation maps in 8.2.1.3.1. Since multiple mappings are defined for several of the 
modulations, the appropriate FEC and code rate description shall be consulted to determine the specific 
mapping to be used. Subclause 8.2.1.4 specifies the modulation procedure to be used for spread-BPSK 
modulation. 



8.2.1.3.1 Constellation mapping 



For the concatenated FEC, code bits shall be mapped to / and Q symbol coordinates using either a pragmatic 
TCM or Gray code symbol map, depending on the code rate and modulation scheme. 

BPSK shall be alternately mapped to the orthogonal constellations illustrated in Figure 170. BPSK MAPO 
shall be used for even-indexed bits, while BPSK MAPI shall be used for odd indexed bits. The first symbol 
to be mapped in a spread BPSK allocation shall be considered even. 



Q 



0 b 0 



BPSK MAPO 
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1 

V 
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Figure 170 — BPSK Constellation maps 



All QPSK code rates and rate 1/2 16-QAM shall use the Gray coded constellation maps depicted in Figure 
171. 
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Figure 171— Gray maps for QPSK and 16-QAM constellations 
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Figure 172— Gray map for 64-QAM constellation 
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Figure 173— Gray map for 256-QAM constellation 



Rate 3/4 16-QAM and all code rates for 64-QAM shall use the pragmatic TCM constellation map depicted 
in Figure 174. 
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Figure 174— Pragmatic maps for 16-QAM and 64-QAM constellations 
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All code rates for 256-QAM shall use the pragmatic TCM constellation map depicted in Figure 175. 
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Figure 175— Pragmatic map for 256-QAM constellation 



To obtain unity average power or unity peak power of transmitted sequences, / and Q coordinates of 
constellation points are multiplied by the appropriate factor for c listed in Table 183, depending on the 
normalization rule in effect. Excepting BPSK, with constant peak power normalization, corner points in the 
constellation are transmitted at equal power levels regardless of modulation type. With constant mean power 
normalization, the signal is transmitted at equal mean power levels regardless of modulation type. 
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Table 183— Unity average power normalization factors 



lVf nriulatiftfi 

itiuu uiaiiuu 

scheme 


Normalization constant for 
unity average power 


Normalization constant for 
unity peak power 


BPSK 


c = 1 


c = 2 


QPSK 


c = \/{Jl) 


c = \/{Jl) \ 


16-QAM 


c = i/(VTo) 


c = 1/(^8) 


64-QAM 


c = 1/(742) 


c = 


256-QAM 


c = 1/(^70) 


c = \/(j45Q) 



8.2.1 .3.2 Spread BPSK modulation 

Spread BPSK is a modulation format. Its selection is made by the burst profile encoding for modulation 

type. 

» 

The input to a spread BPSK modulator is a serial stream of bits derived from the FEC encoder output. 
Spread BPSK modulation shall only be matched with FEC code rates defined for conventional (non-spread) 
BPSK. Table 175 lists these code rates for the mandatory concatenated FEC. 

Figure 176 illustrates the generation of spread BPSK-modulated data with a spreading factor of F s . Each 
input bit shall be held for F s symbol clocks as it is XORed with F s consecutive outputs of a PN sequence 
generator operating at the symbol rate. The XOR output shall be mapped to BPSK symbols as described in 
8.2.1.3.1. 

PN chip generation rate = symbol rate 



PN 



Serial stream of 
coded bits from 
FEC encoder 



uence 
tor 



Spreader 




Alternating 
BPSK constellation 
symbol mapper 



to transmit pules 
shaping filters 



bit input rate = spreaded bit rate= output symbol rate = 

symbol rate/Fs symbol rate symbol rate 

Figure 176— Spread BPSK processing 



Only spreading factors from the set F s = l\ 0 < n < n max , where n max = 3 (for downlink), 4 (for uplink) shall 
be used. Support of all spreading factors is mandatory. The spreading factor used by a burst is specified 
within its burst profile encoding for modulation type. 
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Figure 177— Spreading PN sequence generator 



The spreading PN sequence generator shall be constructed from the Linear Feedback Shift Register (LFSR) 
illustrated in Figure 177. The characteristic polynomial for this LFSR is l +x 21 +x 22 . 

The PN sequence generator shall be preset at the beginning of a spread BPSK allocation with one of the 
seeds listed in Table 184. The burst profile setting for spreading is used to select the seed to be used. 

On the uplink, a BS is not required to make, but may make multiple time-overlapping spread BPSK 
allocations. Each allocation must be to a different SS, and each must use the same seed. These allocations 
shall not time-overlap a non-spread allocation. To insure that spreading sequence phases and preambles of 
overlapping spread BPSK do not time-overlap at the BS receiver, the allocation start-time of a burst 
preamble shall commence at least one Unique Word length of symbols after the end of the preamble of any 
other spread-BPSK allocation that it may time-overlap. 

Multiple time-overlapping spread BPSK allocations (from a single BS, over a single sector) shall not be 
transmitted on the downlink. A recommended practice within a coordinated cell plan is for each BS to assign 
the same seed for all spread BPSK transmissions, and for different BSs in nearby cells or sectors to assign 
different seeds. 
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Table 184— Spreading PN sequence generator seeds 



Seed 
Label 


Seed (Binary) 
MSB LSB 


Seed 
(Hex) 


0 


101 0 1 1 00101 1 1 1001 1 0100 


2B2F34 


1 


10 1 1 1 1 101 00 1001 1 1 1 0 1 1 1 


2FA4F7 


2 


001 1 1 00001 1 00010 101 1 1 1 


E18AF 


3 


1010110001 1001 1001 1001 


2B1999 


4 


1 1 10 1 1001 1 1 1000 1001 1 1 1 


3B3C4F 


5 


10 110 11111100110011011 


2DF99B 


6 


1000 10010001 0 1 1 1 100000 


2245E0 


7 


0 100001 10 1 1 1 1000 101 1 00 


10DE2C 


8 


0100101000000010011011 


12809B 


9 


001000000100101 1 101011 


812EB 


10 


00 10 1 10 1 1000 10 1 1 10 10 10 


B62EA 


11 


10011111011110 00111100 


27DE3C 


12 


0 1 1001 0 1001 1 01 1 1 1 00 1 10 


194DE6 


13 


100001001 01 1 1 10 101 1010 


212F5A 


14 


00 110 10 100 10010011 1000 


D4938 


15 


100001 101 1 100000000001 


21B801 



Note that spread BPSK with a spreading factor of F s divides the throughput by F s on top of all other rate 
reductions such as FEC encoding and mapping to a BPSK symbol constellation. 

8.2.1 .4 Burst set framing 

Both downlink and uplink data shall be formatted into framed burst sets. The downlink shall support one or 
more framed TDM burst sets, while the uplink shall support framed TDMA burst sets. The coordination of 
uplink and downlink bursts used to implement a TDD or FDD system is specified in 8.2.1 .5. 

The format used by a burst set is indicated by the Burst Set Frame Type burst profile encoding (on uplink) 
and extended IE (on downlink). Three formats are defined. The Standard format (8.2.1.4.2) shall be 
supported on both the uplink and downlink. This format is always used for data containing the FCH. The 
STC format (8.2.1.4.3) is optional and shall be used only for STC encoded data on the uplink or downlink. 
The Subchannel format (8.2.1.4.4) is optional and shall be used only on the uplink. 

Although burst sets in the Standard, STC, and Subchannel formats may coexist on the same channel, they 
shall not overlap in time. 
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8.2.1.4.1 Unique Word 

8.2.1.4.1.1 Selection 

The length, (/, in symbols of a Unique Word (UW) is a burst profile parameter (on uplink) and an extended 
IE (on downlink). For best performance, U should be at least as long as the intended channel's span of 
significant delay spread. 

8.2.1.4.1.2 Definition 

Unique Words are derived from Frank-Zadoff sequences [B21] and possess CAZAC (Constant Amplitude 
Zero [periodic] Auto-Correlation) properties. A burst profile specifies a Unique Word from the options listed 
in Table 185. The sequence lengths U = 16 and U = 64 shall be supported. The sequence length U = 256 
shall be supported for bandwidths above 20 MHz. 



Table 185— Unique Word lengths, types, and support 



Length, U (symbols) 


Support status 


16 


Mandatory 


64 


Mandatory 


256 


Mandatory 
for bandwidths above 20 
MHz 



The integer n-indexed / and Q components of a length U, 0 < n < w, Unique Word sequence shall be 
generated from Equation (31). ' , ■ 

/[it] = cos(9[»]) 

Q[n] = sin(6[«]) (31) 
where 

p - ai (32) 

q = 0, 1, ...,JU-1 

and r = 1,3 or co-prime with Jv . 

The length U = 16, 64, and 256 Unique Word sequences are composed of symbols from QPSK, 8-PSK, and 
16-PSK alphabets, respectively. The error vector magnitude (EVM) for Unique Word symbols in a 
transmitter implementation should conform with the general requirements stated in 8.2.3.4. 

For the downlink and uplink, an r-factor value of 1 shall be employed for all instances of UW usage unless 
otherwise specified. For the preamble appearing at the start of each downlink subframe, the r-factor value 
shall be either 1 or 3 and shall be specified by the MAC on a frame-by-frame basis. 

For each downlink burst frame received, the SS PHY shall determine the r-factor of the corresponding 
preamble and provide an indication to the MAC, which provides the r-factor setting for the received frame. 
In addition, the PHY shall use the r-factor to select the appropriate burst profile settings for demodulation 
and decoding of the FCH immediately following the preamble. The FCH burst profile settings associated 
with each r-factor are statically defined at the BS. The SS shall determine these settings during downlink 
synchronization and retain them for use by the SS PHY during normal operation. The settings remain in 
effect until altered by reception of a DL-MAP containing an FCH burst profile change extended IE. 
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8.2.1.4.2 Standard burst set format 

Figure 178 depicts a burst set with the standard format. As illustrated, the burst set consists of three 
fundamental framing elements: a burst set preamble that includes ramp-up; one or more bursts; and a 
Receiver Delay Spread Clearing (RxDS) interval that includes ramp-down. 



H 



Burst Set Preamble 



Burst(s) (and optional Pilot Words) 



RxDS 



RU 



uw 



uw 



RD 



^ . „ Interval for ramp-down 
and delay spread to 
clear receiver 



x „ Ramp-up Ramp-down 

Figure 178 — Fundamental framing elements in a standard format burst set 



8.2.1.4.2.1 Burst set preamble 

A burst set preamble shall consist of a ramp-up region followed by a preamble body. Burst profile (on 
uplink) or extended IE (on downlink) parameters shall specify R r the length of the ramp-up region in 
symbols, and m, the number of Unique Words composing the preamble body. The preamble specification 
shall also include U, the number of symbols in a Unique Word. 



A burst set preamble shall be constructed from the last R r symbols of a Unique Word (see Table 185) 
followed by an integer multiple m S 0 of Unique Words, each Unique Word being U symbols in length. 
Figure 179 illustrates this requirement. 

H=R r +mU symbols ( m > 0 ) 



Burst set preamble 



preamble body: ml) symbols 



Ramp-up 


UW 






*Last/?* 

symbols 
ofUW 


« u * 



Figure 179— Burst set preamble composition 



For R r > 0, a ramp-up element of length R r symbols shall be created and a power ramp-up applied to these 
ramp-up symbols. When creating a ramp-up element, the transmit filter memory is initialized with zero- 
valued (null) symbols. The ramp-up and preamble symbols shall then be sequentially fed into the transmit 
filter input stream. The transient samples preceding the first ramp-up symbol shall be suppressed at the 
transmit filter output until the central sample time of the first preamble symbol. A ramped power buildup 
shall be achieved by superimposing a multiplicative raised cosine half-window of duration R r symbols upon 
the samples leaving the transmit filter. 

For R r = 0, dedicated ramp-up symbols are not inserted. If ramp-up is required, power ramp-up shall be 
applied to the first four symbols of the preamble using the same ramping procedure described for the R r > 0 
case. 
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8.2.1.4.2.2 Burst 

The burst block depicted in Figure 178 contains payload data. The burst block may also contain periodically 
inserted Pilot Words (see 8.2.1.4.2.4). The capability to demodulate payloads of arbitrary length and PS-unit 
granularity is mandatory. The capability to insert Pilot Words at the transmitter and remove them at the 
receiver is also mandatory. 

A downlink burst set may contain time division multiplexed bursts that are adaptively modulated for the 
intended recipients. When an FCH is to be transmitted within a downlink subframe, it shall always appear as 
the first burst in the first burst set, and shall be encoded in accordance with 8.2.1 .7. Subsequent bursts within 
the burst set shall be sequenced in decreasing order of modulation robustness/ beginning with the most 
robust modulation that is supported at the transmitter. The capability to transition between modulation types 
on any PS boundary within a burst set shall be supported. FEC blocks shall be terminated at every such 
transition. 

One exception to the modulation sequencing rule is null payload fill, which if used, shall always appear as 
the final burst in a burst set, and shall be transmitted using QPSK. 

An uplink burst set contains a single burst. 

Burst profiles are used to specify the modulation and coding for each burst. In changing from the preamble 
to a burst or in changing from one burst (e.g., modulation type) to another, the BS or SS shall use one of two 
power adjustment rules: maintaining constant constellation peak power (power adjustment rule = 0), or 
maintaining constant constellation mean power (power adjustment rule = 1). The power adjustment rule is 
configurable through the DCD Channel Encoding parameters (11.4.1) and UCD Channel Encoding 
parameters (11.3.1). 

The constellation normalization factors associated with power adjustment rules are listed in Table 183. 
Preambles and pilot words are derived from PS K alphabets, and use the QPSK normalization factor, 
regardless of the power adjustment rule. 

In changing from one modulation scheme to another, sufficient RF power amplifier margins should be 
maintained to prevent violation of emissions masks. 

Additional description of MAC/PHY support for adaptive modulation and coding is provided in 6.3.7. 

8.2.1.4.2.3 Null payload fill 

When additional payload data is necessary to fill the end of a burst frame, e.g., when a continuous downlink 
does not have enough data to fill a MAC frame, null payload fill may be inserted. The capability to insert 
null payload fill at a transmitter and discard it at a receiver is mandatory. 

Null payload fill shall use the null fill data type. A MAC Frame control (map) message treats the null fill 
data type as an adaptive modulation type, and therefore shall indicate when and for how long this data type 
shall be transmitted within a burst set. Null payload fill data shall also be subject to pilot word patterning 
within a burst set. 

The null fill data type is defined as zero-valued source bits that are randomized (see 8.2.1.1) and mapped 
directly to QPSK symbols using the Gray code map in Figure 171. The randomizer shall run (without reset) 
through both the preceding burst and the null payload fill, but null payload fill shall not be covered (in the 
MAC) by a CRC code. 
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8.2.1.4.2.4 Pilot Words 

A Pilot Word is a contiguous sequence of symbols composed of an integer multiple of Unique Words, which 
may periodically pattern a burst set. As Figure 180 illustrates, the period of a Pilot Word, F (in symbols), is 
defined to include the length, P, of the Pilot Word. For the first downlink burst set containing the FCH, the 
presence of pilot words shall be autodetected during downlink synchronization. Valid values for F and n are 
included in the FCH burst profile definition in 8.2.1.7. For all other downlink burst sets, pilot word 
parameters are specified in the Burst Set Delimiter Extended IE. For uplink bursts, pilot word parameters are 
included in the burst profile specification. 

SS demodulators shall support values of 1024, 2048, and 4096 for F and values of 1, 2, and 3 for n. SS 
modulators shall support values of 256, 512, 1024, 2048, and 4096 for F and values of 1, 2, 3, 4, and 5 for n. 

When Pilot Words are patterned within a burst set, F for that burst set shall be constant, and the first symbol 
of the first Pilot Word shall commence F- P +1 symbols into the burst set. As Figure 180 illustrates, Pilot 
Word patterning shall cease when F- P or less payload data symbols remain in the burst set. 



Burst Set Preamble 



burst(s) (and Pilot Words) 



RxDS 



Burst data 


Pilot 


Burst data 


Pilot 


Burst data 




Word 




Word 





<F-P 



F symbols F symbols 

Figure 180— Pilot Word patterning within a burst set 



8.2.1.4.2.5 RxDS 



The RxDS illustrated in Figure 178 is a quiet period during which the transmitter ramps down, and the 
receiver collects delay-spread versions of symbols at the end of the burst set. The capability to insert the 
RxDS at the transmitter is mandatory. The length of the RxDS shall always be at least the length of a Unique 
Word, unless it is suppressed (i.e., set to length zero). The RxDS is subsumed within transmission gap 
allocations such as the SSTG (on the uplink) or DLBTG (on the downlink), so it requires no explicit 
allocation. 

If the RxDS is nonzero in length, a transmitter shall ramp down during this RxDS by inserting zero inputs 
into the transmit filter memory following the last intended data symbol, and allowing the natural response of 
the filter to drive the filter output to zero. 

8.2.1.4.3 STC burst set format 

Implementation of STC transmit diversity is optional. 

The STC transmit diversity scheme formats pairs of data blocks for transmission over two antennas. 
8.2.1.4.3.1 Paired block transmit processing 

Figure 181 illustrates block pairing that shall be used by the STC transmit diversity scheme. Let {s 0 [n]} and 
{^[n]} represent two sequences, each of length F symbols ( 0<n<F), which are to be delivered to a 
receiver using the STC transmit diversity scheme. Table 186 indicates the block multiplexing structure that a 
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two antenna transmitter shall use to transmit the two sequences using the paired blocks illustrated in Figure 
181. As Table 186 indicates, Transmit Antenna 0 shall transmit its data sequences in order, with no modifi- 
cations; however, Transmit Antenna 1 shall not only reverse the order in which its blocks are transmitted, 
but shall also conjugate the transmitted complex symbols and shall also time-reverse — cyclically about zero, 
modulo-F — the sequence of data symbols within each block. Subclause 8.2.1.4.3.4 provides details on the 
composition of the delay spread guard intervals between the blocks illustrated in Figure 181. 

N-F+U symbols N=F+U symbols 









► 


Delay 
spread 
guard 


F symbols (payload) 


Delay 
spread 
guard 


F symbols (payload) 












Block 0 




Block 1 



Figure 181— Paired blocks used in STC transmit diversity combining 



Table 186 — Multiplexing arrangement for block STC processing 



Tx Antenna 


Block 0 


Block 1 


0 


{s 0 [n}} 


{s { M} 


1 


{-sfUF-^modiF))]} 


{s 0 *[(F-n)mod(F))]} 



8.2.1.4.3.2 Paired block receive processing 

If -V^ 0 ), ff 0 (* /0, )» ff,^"), tfoC* 7 ")' and N i(^ iai ) represent the Discrete-time Fourier transforms, 

respectively, of the symbol sequences {s 0 [n]} and channel impulse responses (for the channels 

associated with each transmitter antenna) {h 0 [n}} and {/^[n]} , and additive noise sequences (associated with 
each. block) {n Q [n]} and , the received signals associated with each block, interpreted in the 

frequency domain, are shown in Equation (33) and Equation (34). 

R 0 (J°) = H^S^-H^S^)^^ (33) 

= H^S^ + H^^^ + N^) (34) 

Assuming that the channel responses H 0 (J") and H x (j") are known, one may use the frequency domain 
combining scheme in Equation (35) and Equation (36). 

C 0 (^) = //oVXc^) + H x {<j")R*{<j») (35) 

CyiJ*) = -H x {j")R^») + H Q *{j»)R l{ j«) (36) 
to obtain the combiner outputs in Equation (37) and Equation (38). 

C 0 (^) = (K(^)| 2 + Mi 2 )S 0 (^) + V(^>o(^) + ^(/Vi^ (37) 
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(38) 



The combiner outputs of Equation (37) and Equation (38) may be independently equalized using frequency 
domain techniques (for an example see Falconer and Ariyavisitakul [B18]) to obtain estimates for {s 0 [n]} 
and {^[n]}. 

8.2.1 .4.3.3 Channel estimation using pilot symbols 

The channel responses used by the equalizer(s) can be estimated using data received during pilot symbol 
intervals. Under the assumption that pilot symbols are the same in the 0 and 1 blocks, i.e., 
sf°\^) = sf to V") = Spuot^") > the sum and differences of Equation (6) and Equation (5) can be 
multiplied by S pilot *{^) to yield (ignoring noise terms)Equation (39) and Equation (40), 



(39) 



(40) 



The channel estimation task simply involves dividing the left hand sides of Equation (28) and Equation (29) 
by a constant independent of frequency, since pilot symbols are derived from the Unique Words of 8.2.1.4.1, 
and these Unique Words have a constant frequency domain magnitude, i.e., \s pilot (J*tf = IwcOl = c • 

8.2.1.4.3.4 Paired block profiles 

Figure 182 and Figure 183 illustrate two defined frame (burst) profiles for STC transmit diversity signaling. 

Figure 182 illustrates the baseline framing structure for STC transmit multiplexing. This is cyclic-prefix- 
based frame structure, with {/-symbol cyclic prefixes (CPs), and F-symbol payload repetitions. Note that 
although the CP is not composed of Unique Words, the length of the CP, U, shall be the same as the Unique 
Word length being used by the burst profile. Observe that the payload portions of Figure 182 reflect the STC 
antenna multiplexing format described in Table 186 for Transmit Antennas 0 and 1. As illustrated in Figure 
183, a Unique Word may be inserted within Pay loads 0 and 1 to facilitate decision feedback equalization at 
the receiver. 
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Figure 182— STC dual blocks without UWs 
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F, the length of an STC block, is a burst profile parameter. The choice of the burst profile for the paired 
blocks, i.e., the scheme illustrated in Figure 182 or the scheme illustrated in Figure 183, is also a burst 
profile parameter. 
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Figure 183— STC dual blocks with UWs 



8.2.1.4.3.5 STC burst set elements 

A STC burst set shall consist of a preamble, followed by burst(s) The burst set may consist of multiple pairs 
of STC blocks. 

Unlike conventional burst sets, an RxDS element shall not appear at the conclusion of a STC burst set. 
8.2.1.4.3.5.1 Burst set preamble 

Figure 184 illustrates that the burst set preamble shall be used for burst sets utilizing STC transmit diversity 
encoding. The number of Unique Word blocks composing a STC burst set preamble is a parameter of the 
Burst Set Delimiter Extended IE (for downlink) or burst profile (for uplink). However, since two channels 
shall be estimated, the total number of UWs used to construct an STC burst set preamble shall be twice the 
parameter value specified. 

Note that this preamble structure may also be inserted within a transmission as a group of contiguous Pilot 
Words, to assist in channel estimation and updating within a burst set. In such an instance, this contiguous 
pilot symbol structure is considered external to the paired STC payload data blocks illustrated in Figure 182, 
although the pilots may appear after every L th paired payload block, where L is an integer greater than or 
equal to 1. 
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Figure 184— STC burst set preamble 



Ramp-up shall use the same procedure described in 8.2.1.4.2.1, with the exception that the ramp-up symbols 
for each transmit antenna are duplicates of the last R r symbols of the first length- U data element in the 
preamble. Note that this implies that the first transmit antenna derives its ramp-up symbols from a standard 
Unique Word sequence {«[«]} , while the second transmit antenna derives its ramp-up symbols from the 
sequence {-u[(U - n)mod(U)]} . 



8.2.1.4.3.5.2 Burst set payload data 



Payload data within an STC-encoded burst set shall be formatted into block pairs, with each block pair 
possessing one of the block pair profiles described in 8.2.1.4.3.4. If insufficient data is available to fill the 
last block pair, then the payload shall be filled with null payload fill, as specified in 8.2. 1.4.2.1. -Except for 
the payload fill, modulations are sequenced in terms of decreasing modulation robustness on the Tx Ant 0 
channel. 

The preamble structure of Figure 184, minus the ramp-up symbols, may also be inserted within a 
transmission, as a group of contiguous Pilot Words to assist in channel estimation and updates within a burst 
set. In such an instance, this contiguous pilot symbol structure is considered external to the paired STC 
payload data blocks illustrated in Figure 182, although the pilots may appear after every V th paired payload 
block, where K is an integer greater than or equal to 1. The pilot word repetition interval, and the number of 
UWs composing a pilot word are parameters of the Burst Set Delimiter Extended IE (for downlink) or the 
burst profile (for uplink) defining the start of the STC-encoded burst set. 

8.2.1.4.3.5.3 Ramp-down 

Ramp-down follows the end of a burst set. A transmitter shall ramp down by inserting zero symbol inputs 
into the transmit filter memory following the last intended data symbol, and windowing the resulting, 
transmit-filtered output waveform with a multiplicative raised cosine window that diminishes to zero in R r 
symbols. The (STC burst) ramp-down interval, R r shall be the same as the ramp-up interval. 

8.2.1.4.3.6 Interoperability with non-STC-encoded burst sets 

For interoperability reasons, STC-encoded data and conventionally-encoded data, shall not be time division 
multiplexed within the same burst set. Instead, STC data shall be encapsulated within its own burst set. 

All burst sets with different STC pair block sizes, F, shall also be segregated, although they may share the 
same preamble. 

8.2.1.4.4 Subchannel burst set format 

The subchannel burst set format is used to frame burst sets that are transmitted on subchannels. 
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8.2.1.4.4.1 Framing procedure 

A payload shall be formatted into a subchannel burst set using the following procedure: 

1) Form a Base frame by attaching a burst set preamble to the burst(s) as shown in Figure 185. The 
preamble shall be constructed from m repeated Unique Words, as specified in the burst profile for 
Preamble parameters, but without the additional ramp-up symbols. The Unique Word length, U, is a 
burst profile parameter. 



mU 



Preamble 



Burst(s) 



UW 



uw 



Figure 185 — Base frame 



2) Partition the Base frame into Blocks of length b as shown in Figure 186, padding the frame with 
MAC padding data as necessary to fill the last Block. The value to be used for b is indicated in 
8.2.1.4.4.3. 
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Figure 186— Base frame partitioning and padding 

3) Suffix each Block with a Known Word composed of k Unique Words to form Appended Blocks, as 
shown in Figure 187, where k is a burst profile parameter. 
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Figure 187— Forming an appended block 



Copyright ©2004 IEEE. All rights reserved. 



387 



lEEEStd 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



4) Form Repeat Segments as shown in Figure 188 by concatenating N r copies of each Appended Block. 
The value to be used for N r is indicated in 8.2.1.4.4.2. 
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r = N r a 
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Figure 188 — Forming a repeat segment 

5) Form Burst Set Segments as shown in Figure 189, by prefixing each Repeat Segment with a Cyclic 
Prefix (CP) of length dU symbols and a Known Word. Each Cyclic Prefix of a Repeat Segment is 
composed of the last dU symbols in that Repeat Segment d is a burst profile parameter. 
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Figure 189— Forming a burst set segment from repeat segments 
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6) Concatenate Burst Set Segments to form a Subchannel Burst Set, as illustrated in Figure 190. 
Transmitter ramp-up processing is applied to the first data in the burst set; transmitter ramp-down 
processing occurs directly following the last data in burst set. 



s 0 



f=ps 



Subchannel Burst Set 



t f 

Begin Begin 
Ramp-up Ramp-down 

Figure 190— Forming of subchannel burst set from segments 

7) Apply the ramp-up procedure of 8.2.1.4.2.1 to the first 7? r symbols in the subchannel burst set, where 
R r is specified in the Preamble length burst profile encoding. Note, however, that in the context of 
subchannel framing, the preamble length is mU rather than mU + R r 

8) Ramp down by inserting zero inputs into the transmit filter memory following the last data symbol 
in the subchannel burst set, and allowing the natural response of the filter to drive the filter output to 
zero. The ramped down data is not considered part of the subchannel burst set from which it was 
derived. 

The resulting subchannel burst set is transmitted using the procedure described in 8.2.1.4.4.2. 
8.2.1.4.4.2 Subchannel burst set transmission 

When a subchannel burst set is allocated, the UL MAP will indicate the start time and duration, as well as 
the starting subchannel index and number of consecutive subchannels assigned to the subchannel burst set. 
Subchannel assignments shall be selected from a set of N s = 8 subchannels, with indices 
*e{0,l 

Assignments to different subchannels may overlap in time and differ in duration. The SSTG between sub- 
channel burst sets on the same subchannel shall be of length zero, overriding any UCD channel encoding for 
SSTG. In addition, although the assignments for a standard burst set and a subchannel burst set shall not 
overlap, the SSTG between a subchannel burst set followed by a standard burst set shall also have a length 
of zero. However, the SSTG between a standard burst set followed by an SSTG shall comply with the UCD 
SSTG channel encoding. When assigned a starting subchannel index of h t a transmitter shall multiply the 
symbols [I[n], Q[n]} composing a subchannel burst set by the complex exponential sequence in Equation 
(41) 

cW- exppH^) (41) 
to form output symbols 

I° U '[n] +jQ ou '[n}= (/[n] +jQ[n])c[n] (42) 
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where [n] is the discrete time index of a symbol-spaced sampler and r is a burst profile encoding. Output 
symbols shall afterwards be fed to the pulse-shaping transmit filter. 

Channel allocations shall always be consecutive, and allocated as a power of 2. When a subscriber is 
allocated N alloc = 2 8 consecutive subchannels, ge {0, 1, [^Wjl , a transmitter shall apply a repeat 
factor of 



N s 

N = — 

' 2 8 



(43) 



When transmissions on different subchannels overlap in time, their burst profile encodings for U, k, d y and r 
must all be common. Moreover, as illustrated in Figure 196, burst set start times must be allocated such that 
constituent segments are time-aligned, although the start time and duration of independent burst sets may be 
different. 
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Figure 191— Segment alignment for overlapping burst sets on different subchannels 
8.2.1 .4.4.3 Burst profile parameters and derivations 

Burst profile parameters associated specifically with subchannel framing are as follows: 

k - the number of Unique Words (of length IT) composing a Known Word. 
d - the length of a Cyclic Word in integer multiples of U. 
r - the Repeat segment length in symbols. 

UCD encodings for these parameters are found in Table 281, under the name Subchannel framing 
parameters. Note that the combination of [d = 0, k = 0} is not allowed. 

Parameters used in the framing procedure of 8.2.1.4.4.1 are derived as follows [Equation (44)-Equation 
(46)]: 
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r 

a = K 



< 44 > 

r "alloc 



N. 



S 



b = a-kU • (45) 

s = r+(k + d)U (46) 

A burst set of length P symbols, with Preamble of length mU would be formatted into a subchannel burst set 
composed of 

(P + mU)N s 

P = ^/ (4?) 



segments, each of length s, for a total length of 



L frame = + (* + d)U) (48) 

symbols. 



8.2.1.5 Duplex framing 

Subclause 8.2.1.5.1 specifies FDD operation, while 8.2.1.5.2 specifies TDD operation. Support of at least 
one of these two duplexing modes is mandatory. FDD SSs may be half-duplex FDD (H-FDD). 



8.2.1.5.1 FDD 



FDD segregates the uplink and downlink on different-frequency carriers — BSs transmit at the downlink 
carrier frequency, while SSs transmit at the uplink carrier frequency. 

An SS in a FDD system shall be capable of operation over a burst downlink and uplink. Moreover, given ( 
appropriate parameterization of a burst downlink, an SS shall also be capable of continuous downlink 
operation. 

8.2.1 .5.1 .1 FDD with burst downlink 

An example FDD system with TDM downlink is illustrated in Figure 192. As Figure 192 illustrates, down- 
link and uplink subframes shall coincide in length, and shall repeat at regular (MAC-defined) constant 
intervals. 

A downlink burst frame shall not exceed the length of a downlink subframe, but it need not fill the entire 
downlink subframe. Also, although not illustrated in Figure 192, the capability to support several downlink 
burst sets within a downlink subframe is mandatory. 

The first burst set in each downlink subframe shall commence with a burst set preamble (BP), and shall be 
directly followed by a Frame Control Header (FCH), a payload that may contain DCD, UCD, and MAPs. 
Only the first burst set in a downlink subframe shall contain the FCH. 



Data within the FCH payload shall be encoded in accordance with 8.2.1.7. 
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Figure 192— Example of FDD frame format 



Time division multiplexed downlink bursts may follow the FCH. A downlink burst set concludes with an 
RxDS to allow delay spread to clear the receiver. In the event that a downlink MAC frame is entirely filled 
with data, bursts may be concatenated and the RxDS suppressed. In other words, an RxDS of zero length 
shall be used, so that no ramp-down occurs, and the Preamble of the next MAC frame may immediately 
commence. The preamble of that next MAC frame shall then use a ramp-up parameter R r of zero, so that no 
ramp-up occurs. 

When more than one burst set is to be transmitted within a single downlink MAC subframe, the DL-MAP 
shall include a Burst Delimiter Extended IE after the last data grant IE of each burst set and before the first 
data grant IE of the burst set's successor. The IE specifies the size of the gap (DLBTG) separating the burst 
sets. The gap includes the RxDS. As a result, the minimum length of the DLBTG is the length of the RxDS. 

An uplink subframe contains three categories of bursts: 

— Initial Ranging requests that are transmitted in contention slots reserved for station initial ranging. 

— Bandwidth Requests that are transmitted in contention slots reserved for response to multicast and 
broadcast polls for bandwidth needs. 

— Grants of bandwidth that are specifically allocated to individual SSs. 

As Figure 192 illustrates, uplink burst sets are TDMA, and shall be constructed from a burst set preamble 
(BP), including ramp-up; a burst; and an RxDS, including ramp-down. SSTGs separate the burst set 
transmissions of the various SSs using the uplink. An SSTG specification includes the length of the RxDS, 
along with any additional guard symbols that may be inserted between uplink bursts to reflect reference time 
uncertainties. 
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All uplink burst sets excluding Initial Ranging slots shall use an SSTG (between bursts) that is specified as a 
UCD Channel Descriptor parameter. Since larger time uncertainties may be experienced on the Initial 
Ranging slots, a special Initial Ranging SSTG Channel Descriptor parameter shall be associated with the 
Initial Ranging slots. The Initial Ranging SSTG specification includes both the length of the RxDS and 
additional guard symbols. The additional guard symbols used by the Initial Ranging SSTG are designated by 
"GS" in Figure 192. 

The UL-MAP in the downlink FCH governs the location, burst size, and burst profiles for exclusive 
bandwidth grants to SSs. Burst profile selection may be based on the effects of distance, interference and 
environmental factors on transmission from the SS. 

8.2.1.5.1.2 Generating a continuous downlink from a burst downlink 

A continuous downlink may be derived from a burst downlink by null pay load filling the end of a burst 
frame, to insure that it spans an entire downlink frame. By so doing, a burst downlink is forced to suppress 
both the RxDS and ramp-up burst elements, because burst downlinks are mandated to suppress these 
elements when a downlink MAC subframe is full. To insert null payload fill, the last entry in the DL-MAP 
of an FCH shall specify the burst profile for the null fill data type. Details on the null payload fill data type 
can be found in 8.2. 1 .4.2.3. 

8.2.1.5.1.3 FDD Channel and Burst Descriptor field definitions 
DL Channel Descriptor Parameters 

Each DCD message channel descriptor shall include the following TLV encodings: 
DownlinkJBurst_Profile 
BS EIRP 

Power adjustment rule 

RSS IR,max 
MAC version 

DL Burst Descriptor Parameters 

Each DCD message burst descriptor shall include the following TLV encodings: 
Modulation type 
RS information bytes 
RS parity bytes 

DIUC mandatory exit threshold 
DIUC minimum entry threshold 
CC/CTC-specific parameters 
Each DCD message burst descriptor may include the following additional TLV encodings: 
Block interleaver depth 
BTC code selector 
Spreading parameters 
CID_In_DL_IE 

UL Channel Descriptor Parameters 

Each UCD message channel descriptor shall include the following TLV encodings: 
Uplink_Burst_Profile 
Symbol rate 
Frequency 
SSTG 

Roll-off factor 
Power adjustment rule 
Contention-based reservation timeout 
Initial ranging SSTG 
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UL Burst Descriptor Parameters 

Each UCD message burst descriptor shall include the following TLV encodings: 
Modulation type 
Preamble length 
RS information bytes 
RS parity bytes 
CC/CTC-specific parameters 
Unique Word Length 
Pilot word parameters 
Burst set type 

Each UCD message burst descriptor may include the following additional TLV encodings: 
Block interleaver depth 
STC parameters 
BTC code selector 
Spreading parameters 
Subchannel framing parameters 

8.2.1.5.2 TDD 

TDD multiplexes the uplink and downlink on the same carrier, over different time intervals within the same 
MAC frame. 

Figure 193 illustrates TDD operation with a single burst set on the TDM downlink. In TDD, the downlink 
and uplink alternate occupying a shared frame, with the downlink subframe preceding the uplink subframe. 
The size of the shared frame shall be constant; however, the downlink and uplink subframe sizes within the 
shared frame shall vary according to allocations directed by the FCH. Although Figure 193 illustrates a 
single TDM burst set per downlink subframe, the capability to accommodate several TDM burst sets is 
mandatory, with the first burst set in the downlink duplex subframe containing the FCH. 

When more than one burst set is to be transmitted within a single downlink subframe, the DL-MAP shall 
include a Burst Delimiter Extended IE after the last data grant IE of each burst set and before the first data 
grant IE of the burst set's successor. The Burst Delimiter Extended IE specifies the size of the gap (DLBTG) 
separating the burst sets. The gap includes the RxDS. As a result, the minimum length of the DLBTG is the 
length of the RxDS. 

Most framing elements within TDD are found in FDD and perform the same functions; therefore, for 
descriptions of these elements, consult 8.2.1.5.1.1. The only frame elements in TDD not found in FDD are 
TTG and RTG. 

After the TTG, the BS receiver shall look for the first symbols of the uplink subframe. This gap is an integer 
number of PS durations and starts on a PS boundary. 

After the RTG, SS receivers shall look for the first symbols of modulated data in the downlink subframe. 
This gap is an integer number of PS durations and starts on a PS boundary. 

8.2.1.5.2.1 TDD Channel Descriptor field definitions 

DL Channel Descriptor Parameters 

Each DCD message channel descriptor shall include the following TLV encodings: 
Downlink_Burst_Profile 
BSEIRP 

Power adjustment rule 
TTG 
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Figure 193— Example of TDD frame format 



RTG 
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MAC version 



DL Burst Descriptor Parameters 

Each DCD message burst descriptor shall include the following TLV encodings: 
Modulation type 
RS information bytes 
RS parity bytes 

DIUC mandatory exit threshold 
DIUC minimum entry threshold 
CC/CTC-specific parameters 
Each DCD message burst descriptor may include the following additional TLV encodings: 
Block interleaver depth 
BTC code selector 
Spreading parameters 
CID_In_DL_IE 

UL Channel Descriptor Parameters 

Each UCD message channel descriptor shall include the following TLV encodings: 
Uplink_Burst_Profile 
Symbol rate 
Frequency 
SSTG 
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Roll-off factor 
Power adjustment rule 
Contention-based reservation timeout 
Initial ranging SSTG 

UL Burst Descriptor Parameters 

Each UCD message burst descriptor shall include the following TLV encodings: 
Modulation type 
Preamble length 
RS information bytes 
RS parity bytes 
" CC/CTC-specific parameters 
Unique word length 
Pilot word parameters 
Burst set type 

Each UCD message burst descriptor may include the following additional TLV encodings: 
Block interleaver depth 
STC Parameters 
BTC code selector 
Spreading parameters 
Subchannel framing parameters 

8.2.1.6 Support for AAS 

Discussion in 8.2.1.4 and 8.2.1.5 specifies the requirements for implementation of systems supporting 
unicast BS transmissions on the downlink, and except in special cases, non-overlapped SS transmissions on 
the uplink. AAS techniques provide the ability to relax some of those constraints with the benefit of 
enhancing overall system performance. This subclause describes WirelessMAN-SCa support for AAS. In 
instances regarding system operation using AAS where there is conflict between requirements imposed by 
other portions of this document and this subclause, the specifications provided by this subclause shall take 
precedence. 

Implementation of support for AAS at either BS or SS is optional. 
8.2.1.6.1 Preamble definitions 

Two classes of AAS Preambles are defined, based on the baseline preamble definition with r =1 and r = 3. 
Within each class are four preambles, indexed p e {0, l, 2, 3} . 

An AAS preamble shall consist of a base preamble (parameterized by r = 1 or r = 3) multiplied by one of 
four different phase ramp sequences, selected by the index p. 

A base preamble shall be constructed from 5 Unique Words, each of length U and parameterization r = 1 or 
r = 3 (see 8.2.1.4.2.1). U shall be the same as that used by Unique Words in the downlink broadcast FCH 
preamble. The AAS transmission context determines selection of the r = 1 or r = 3 parameterization. 

The multiplicative phase ramp sequence associated with a preamble of index p is shown in Equation (49). 



where j = V^T , [n] is the discrete time index of a symbol-spaced sampler, n = 0 is the time index of the first 
symbol, and n = 5U-1 is the time index of the last symbol. 




(49) 
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8.2.1.6.2 Power ramp-up 



Transmitter power shall be ramped up over the first four symbols in the preamble. When creating a ramp-up 
element, the transmit filter memory is initialized with zero-valued (null) symbols. The preamble symbols 
shall then be sequentially fed into the transmit filter input stream. The transient samples preceding the first 
ramp-up symbol shall be suppressed at the transmit filter output until the central sample time of the first 
preamble symbol. A ramped power buildup shall be achieved by superimposing a multiplicative raised 
cosine half-window of duration four symbols upon the samples leaving the transmit filter. 

8.2.1.6.3 Power ramp-down 

All AAS elements, including bursts and burst sets, shall ramp down their power at the end of transmission. 
Power is ramped down by using-the natural response of the pulse-shaping filter to gradually drive the 
transmitter output to zero once source symbols are exhausted. 



8.2.1.6.4 Frame element formats 



Elements associated with AAS transmission include an AAS-indicator, an AAS-alert slot, AAS-formatted 
downlink subframes, and AAS-formatted uplink bursts. An example of the content of MAC frames when 
AAS elements are included is presented in Figure 180. 
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Figure 194— MAC frame contents with AAS elements 



8.2.1.6.4.1 AAS-indicator 

An AAS-indicator shall be composed of class r 
antenna) and no payload. 



= 3 AAS preambles (one preamble per transmission 



An AAS-indicator is simultaneously transmitted on up to 4 BS antennas, with each antenna using a different 
multiplicative phase ramp index p. A larger total number of BS antennas may be accommodated by varying 
the set of antennas used from transmission to transmission. 

An AAS -enabled SS shall be capable of phase deramping to separate each of the concurrent BS antenna 
transmissions and then estimating the CINR, RSSI, and carrier phase (measured over 4 UWs) for each 
transmission. Carrier phase measurement precision shall be no less than 11.25 degrees. 

When it is included, the AAS-indicator shall appear as the first element of the AAS portion of the downlink 
subframe at the offset specified by the downlink subframe FCH DL-MAP AAS extended IE. 
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8.2.1 .6.4.2 AAS-aiert slot 

An AAS-alert is transmitted within an AAS-alert slot on the uplink. An AAS-alert consists of an r = 1 AAS 
preamble followed by a payload of fixed length known to the MAC. The payload is encoded using the 
baseline concatenated FEC, with rate 1/2 BPSK convolutional code. 

The index,/?, of the preamble is selected randomly by the SS. 

The alert slot, when it is present, is located at the end of the uplink subframe, immediately before the MAC 
frame RTG 

8.2.1 .6.4.3 Downlink AAS subframe 

A downlink AAS subframe contains payload data directed to one or more AAS subscribers. Subject to the 
capabilities of the BS, multiple AAS subframes may be transmitted within the AAS portion of the downlink 
subframe. Those subframes may be concurrent or sequential in time. 

A downlink AAS subframe transmission consists of an AAS preamble followed by payload data consisting 
of one or more bursts or burst sets (standard or STC). The preamble parameter r is set to 3. Before and 
during initial network entry, the value of the index p shall be the same as the index value used by the SS for 
its uplink alert slot transmission. Once network entry has been achieved and the SS is receiving DL-MAPs, 
use of the original value employed during network entry is maintained until it is overridden by a notification 
from the BS. The modulation type, length, and FEC are determined by the AAS DL-MAP. The first burst 
following the preamble shall be an FCH that is encoded using the baseline concatenated FEC, with rate 1/2 
BPSK convolutional code. 

8.2.1.6.4.4 Uplink AAS burst 

An uplink AAS burst is transmitted in the AAS portion of the uplink subframe. Subject to the capabilities of 
the BS, multiple AAS bursts may be transmitted within the AAS portion of the uplink subframe. Those 
bursts may be concurrent or sequential in time. 

An AAS burst contains payload data from an AAS-enabled subscriber with formatting of the transmission 
specified by the contents of a UL-MAP arriving at the SS in either a downlink subframe FCH or an AAS- 
FCH. Burst types transmitted in the AAS portion of the uplink frame may be any of the frame types 
available to non-AAS enabled SS: standard, subchannel, or STC. For standard bursts, an AAS preamble 
shall be used with the value of r set to 1 and the value of p specified in the UL-MAP For STC or subchannel 
bursts, the preamble used shall conform to the preamble format prescribed for the corresponding burst type. 

8.2.1 .6.5 AAS-enabled operations 

WirelessMAN-SCa support for AAS follows the general discussion appearing in 6.3.7.6. 

8.2.1.6.5.1 Downlink synchronization 

Downlink network synchronization of AAS-enabled SS shall be accomplished by detecting and 
synchronizing with the FCH burst set preamble transmitted at the start of each downlink subframe. 

8.2.1.6.5.2 Network entry 

For AAS-enabled SS that can decode the downlink subframe FCH, network entry shall be carried out as 
prescribed in 6.3.9. 
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For situations where the FCH contents cannot be decoded, the procedure outlined in 6.3.9 shall apply except 
for the actions taken to initiate and complete the first initial ranging RNG-REQ/RSP dialog. 

When FCH contents cannot be decoded, the SS shall monitor each downlink subframe transmission for the 
occurrence of an AAS-indicator sequence. The presence of this sequence shall indicate the availability of an 
AAS-alert slot in the frame following the frame containing the sequence. 

An AAS-alert slot is similar to an initial ranging slot used for conventional network entry and shall be sized 
to allow transmission of a RNG-REQ message (the size prescribed in 6.3.2.3.5 and 6.3.9 for initial ranging 
request message plus the size of the SCa AAS feedback and AAS broadcast capability TLVs) and the 
appropriate burst preamble, and shall also account for the maximum round-trip propagation delay between a 
BS and the most distant SS to be serviced. The size and location of the of the slot in the uplink subframe 
shall be well-known. The SS shall initiate transmission in the alert slot assuming the SS is co-located with 
theBS. 

The following discussion references start and end parameters for the exponential backoff algorithm used for 
the initial ranging dialog of AAS subscribers. The well-known values for these parameters shall be start = 3, 
and end = 8. 

8.2.1.6.5.2.1 AAS-alert transmissions decodable at BS 

Upon reception of an alert slot transmission, if the BS can decode the transmission, it shall format a response 
in the form of a RNG-RSP message based on the information provided in the AAS-alert RNG-REQ message 
and data collected during reception. The response shall be transmitted in the AAS portion of a subsequent 
DL frame using the same preamble index (p) as that used for the AAS alert RNG-REQ transmission. The 
RNG-RSP response is equivalent to the response to a decodable initial ranging RNG-REQ message as 
described in 6.4.9, terminating the initial net entry RNG-REQ dialog. The transmission containing the RNG- 
RSP message shall also include DCD and UCD messages. 

Once an alert slot transmission has been made, the SS shall await a response as specified by 6.3.9. If no 
response is received, a new alert slot is selected in accordance with the exponential backoff algorithm 
specified in 6.3.8. The starting and end backoff values shall be well-known (8.2.1.6.5). Once the new alert 
slot has been selected, the RNG-REQ alert slot transmission process is repeated. 

8.2.1.6.5.2.2 AAS-alert transmissions undecodable at BS 

In the event a transmission is detected but the uplink alert message cannot be decoded, the BS shall format a 
RNG-RSP message based on the data collected during reception and specify the frame in which the alert was 
sent using the Frame number TLV. The message shall not include the Initial ranging opportunity TLV. The 
response shall be transmitted in the AAS portion of a subsequent DL frame using the same preamble index 
(p) as that used for the AAS-alert RNG-REQ transmission. The RNG-RSP response is similar to the 
response to an undecodable initial ranging RNG-REQ message as described in 6.3.9. The transmission 
containing the RNG-RSP message shall also include DCD and UCD messages. 

Once the alert slot transmission has been made, the SS shall await a response as specified by 6.3.9. If no 
response is received, a new alert slot is selected in accordance with the exponential backoff algorithm 
specified in 6.3.8. The starting and end backoff values shall be well-known (8.2.1.6.5). Once the new alert 
slot has been selected, the RNG-REQ alert slot transmission process is repeated. 

If the RNG-RSP message with the Frame number TLV is received, the SS shall await notification in an 
arriving AAS-FCH UL-MAP that an initial ranging contention slot grant has been scheduled. The size of 
this slot shall be the same as the AAS-alert slot. The SS shall respond to the grant by formatting and sending 
a RNG-REQ message (with SCa AAS feedback and AAS broadcast capability TLVs) in that slot. The 
preamble index shall be the same as that used in the most recent AAS-alert slot transmission. 
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If the transmission is detected at the BS, an appropriate RNG-RSP message is formatted based on whether or 
not the BS was able to decode the content of the transmission and the message is transmitted in the AAS 
portion of a subsequent DL frame using the same preamble index (p) as that used for the RNG-REQ 
transmission. 

Successful reception of a response to a RNG-REQ decoded by the BS is equivalent to the response to a 
decodable initial ranging RNG-REQ message as described in 6.3.9, terminating the initial net entry RNG- 
REQ dialog. 

Successful reception of a response to a RNG-REQ that could not be decoded by the BS indicates that the SS 
shall wait for another contention initial ranging grant opportunity and repeat the process described in this 
subclause. 

If the SS does not receive a response to its contention slot transmission, in accordance with the timeout 
limits specified in 6.3.9, a new alert slot is selected in accordance with the exponential backoff algorithm 
specified in 6.3.8. The starting and end backoff values shall be well-known (8.2.1.6.5). Once the new alert 
slot has been selected, the RNG-REQ alert slot transmission process is repeated. 

8.2.1.6.5.3 Data exchange 

When AAS operations are active, the downlink and uplink subframes shall be partitioned into portions 
dedicated to AAS and non-AAS usage. The first part of each subframe shall be allocated to non-AAS 
operations, with any remainder allocated for AAS activities. AAS extended IEs are included in the FCH DL- 
MAP and the UL-MAP to specify the location of the boundary between the partitions. 

Downlink AAS transmissions including responses to alert slot RNG-REQ messages shall consist of a 
preamble followed by an FCH burst, and optionally, one or more data bursts and/or additional burst sets. The 
BS shall not allow concurrent AAS transmissions that are initiated by the same AAS preamble. 

The format of the content of an AAS FCH shall conform to the format of the FCH appearing at the start of 
the downlink subframe with the exception that RNG-RSP messages may be carried in the AAS -FCH rather 
than in a subsequent burst. The order of appearance of messages in the AAS-FCH shall be DL-MAP, UL- 
MAP, DCD, UCD, and RNG-RSP. In addition, WirelessMAN-SCa AAS implementations shall not support 
private maps where broadcast CID values are replaced with the basic CID of an SS. 

For an AAS-capable SS able to decode the downlink subframe FCH, the SS shall enable its receiver for all 
non-AAS transmissions it is capable of receiving. It shall also enable its receiver at the start of the AAS 
portion of the downlink subframe, and having detected an appropriate preamble, it shall receive and decode 
the data stream (AAS-FCH and data bursts) following each such preamble. The receiver shall be disabled at 
the start of the TTG at the end of the DL subframe. 

For AAS-capable SS unable to decode the downlink subframe FCH, the SS shall enable its receiver at an 
offset into the frame at or before the location corresponding to the end of the XFCH portion of the FCH, and 
having detected an appropriate preamble, it shall receive and decode the data stream (AAS-FCH and data 
bursts) following each such preamble. The receiver shall be disabled at the earlier of the following three 
frame locations— if known, at the end of the downlink subframe; at the start of the AAS-alert slot, if one is 
present; or at the start of the RTG at the end of the uplink frame. 

Just as in the non-AAS case, AAS uplink transmissions after net entry are governed by the BS through 
bandwidth allocations. For AAS-capable SS able to decode the downlink subframe FCH,. the SS may 
respond to either grants indicated in the downlink subframe FCH UL-MAP or in the UL-MAP appearing in 
an AAS-FCH burst. For AAS-capable SS unable to decode the downlink subframe FCH, the SS shall 
transmit only in grants indicated in the UL-MAP appearing in an AAS-FCH burst. 
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8.2.1 .6.6 Channel measurement 

8.2.1.6.6.1 DL subframe preamble 

Measurements regarding the DL subframe preamble used for network synchronization and network entry 
shall be collected by the SS and reported to the BS using the REP-REQ/RSP message dialog. Reports to the 
BS may occur in response to a request from the BS or may be issued asynchronously by the SS. 

8.2.1.6.6.2 AAS feedback 

Information on BS AAS transmissions shall be collected by the SS each time it detects an AAS-indicator 
transmission. At the initial phase of network entry, this information shall be provided to the BS in the alert 
transmission. 

Following network entry, the information shall be provided using the AAS-FBCK message dialog. Reports 
to the BS may occur in response to a request from the BS or may be issued asynchronously by the SS. 

8.2.1.7 Frame Control Header burst profile 

A compliant SS shall be capable of demodulating a FCH with the parameters listed in Table 187 and Table 
188; a compliant BS shall be capable of transmitting FCHs using one of these sets. This information shall be 
well-known and shall not appear in the DCD burst profile definitions. 



Table 187— Channel settings for FCH burst 



DCD channel profile parameter 


Default setting 


Alternative that shall be 
supported by auto-detection 


Roll-off factor 


0.25 




Preamble length 


length = mU + R r 
m - 3 repeated UWs 
R r = 4 ramp symbols 


0<R r <min(U/2, 60) 
in increments of 4 symbols 


Unique Word length 


U = 64 symbols 


U = 16,256 symbols 


Pilot Word Interval 


No Pilot Words 


1024, 2048 or 4096 


Unique Word Count 


No Pilot Words 


1,2, or 3 


Power adjustment rule 


0 (preserve peak power) 


1 (preserve mean power) 
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Table 188— Burst profile settings for FCH burst 



DCD burst Profile 
Parameter 


Unique Word 
r-factor = 1 


Unique Word 
r-factor = 3 


Modulation type 
(FCH payload) 


QPSKor 16-QAM 
determined by auto-detect. 

Concatenated FEC without 
block interleaving 


DS-BPSK with spread length 
(Fs =1 ,2, or 8) determined by 
auto-detect, 

Concatenated FEC without 
block interleaving 


Inner (CC) code rate 
(FCH payload) 


1/2 


1/2 


RS Parameters 


base K = 239 bytes, 
K variable via shortening 
with fixed R - N - K - 16 
bytes 


base K = 239 bytes, 
K variable via shortening 
with fixed/? = N-K = 16 
bytes 


Burst set type 


Standard 


Standard 



The first X FCH source bytes of the FCH shall be outer encoded using a shortened RS code word specified by 
RS(N = X FCH + 16, K = X FCH ). This shortened code block shall then be inner encoded, and the inner code 
terminated at the end of the code block. The remainder of the FCH payload shall be encoded within one or 
more RS(N = 255,^ = 239) code words, with the last code word shortened to RS(tf last + 16,tf last ) if K lm < 39. 

X FCH is constant and the minimum byte capacity of the FCH burst. Its value shall span the content of a 
compressed DL-MAP message (8.2.1.8.1) up to and including the contents of the second data grant IE 
appearing in the downlink subframe (if one exists). Any unused bytes in the X FCH region of the FCH shall be 
filled in accordance with 6.3.3.7. 

8.2.1.8 Compressed FCH maps 

The DL-MAP appearing in the FCH shall conform to the compressed format presented in this subclause. 
UL-MAP messages appearing in the FCH may conform to either the standard format described in 6.3.2.3.4 
or the compressed format presented in this subclause. 

The presence of the compressed DL-MAP format is indicated by the contents of the most significant two bits 
of the first FCH data byte. These bytes overlay the HT and EC bits of a generic MAC header. When these 
bits are both set to 1 (an invalid combination for a standard header), the compressed DL-MAP format is 
present in the FCH. A compressed UL-MAP shall only appear after a compressed DL-MAP. The presence of 
a compressed UL-MAP is indicated by a bit in the compressed DL-MAP data structure. 

8.2.1.8.1 Compressed DL-MAP 

The compressed DL-MAP format is presented in Table 189. The message presents the same information as 
the standard format with one exception. In place of the DL-MAP's 48-bit Base Station ID, the compressed 
format provides a subset of the full value. When the compressed format is used, the full 48-bit Base Station 
ID shall be published in the DCD. 



Compressed map indicator 

A value of binary 11 in this field indicates the map message conforms to the compressed format 
described here. A value of binary 00 in this field indicates the map message conforms to the 
standard format described in 6.3.2.3.2. Any other value is an error. 
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Table 189— SCa compressed DL-MAP format 



Syntax 


Size 


Notes 


SCa_Compressed_DL-MAP() { 






Compressed map indicator 


2 bits 


Set to binary 11 for compressed format 


reserved 


1 bit 


Shall be set to zero 


Compressed UL-MAP appended 


1 bit 




CRC appended 


1 bit 




Compressed message length 


11 




PHY Synchronization 


24 bits 




DCD Count 


8 bits 




Operator ID 


8 bits 




Sector ID 


8 bits 




DL IE count 


8 bits 




for (i = 1; i <= DL IE count; { 






DL-MAP JEO 


variable 




} 






if !(byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary 


} 






} 







Compressed UL-MAP appended 

A value of 1 indicates a compressed UL-MAP (see 8.2.1.8.2) is appended to the current 
compressed DL-MAP data structure 
CRC appended 

A value of one indicates a CRC-32 value is appended to the end of the compressed map(s) data. 
The CRC is computed across all bytes of the compressed map(s) starting with the byte containing 
the Compressed map indicator through the last byte of the map(s) as specified by the Compressed 
message length field. The CRC calculation is the same as that used for standard MAC messages. A 
value of zero indicates that no CRC is appended. 
Compressed message length 

This value specifies the length of the compressed map message(s) beginning with the byte 
containing the Compressed map indicator and ending with the last byte of the compressed DL- 
MAP message if the UL-MAP appended bit is not set or the last byte of the UL-MAP compressed 
message if the UL-MAP appended bit is set. The length includes the computed 32-bit CRC value if 
the CRC appended indicator is on. 
PHY Synchronization 

This field holds frame number information. See 8.2.1.9.1 and Table 191. 
DCD Count 

Matches the value of the configuration change count of the DCD, which describes the downlink 
burst profiles that apply to this map. 
Operator ID 

This field holds the least significant 8 bits of the most significant 24 bits of the 48-bit Base Station 
ID. 

Sector ID 

This field holds the least significant 8 bits of the 48-bit Base Station ID. 
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DL IE count 

This field holds the number of IE entries in the following list of DL-MAP IEs. 
8.2.1.8.2 Compressed UL-MAP 

The compressed UL-MAP format is presented in Table 190. The message may only appear after a 
compressed DL-MAP message to which it shall be appended. The message presents the same information as 
the standard format with one exception. The Uplink Channel ID is omitted. A value of zero shall be assigned 
to this parameter. 



Table 190— SCa compressed UL-MAP format 



Syntax 


Size 


Notes 


SCa_Compressed_UL-MAP() { 






UCD Count 


8 bits 




Allocation Start Time 


32 bits 




while (map data remains) { 






UL-MAPJE0 


variable 




} 






if !(byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary 


} 






} 







UCD Count 

Matches the value of the Configuration Change Count of the UCD which describes the uplink burst 
profiles that apply to this map. 
Allocation Start Time 

Effective start time of the uplink allocation defined by the UL-MAP. 
8.2.1.9 MAP message fields and IEs 
8.2.1 .9.1 DL-MAP PHY synchronization field 

Table 191 provides the format of the PHY synchronization field of the frame control message described in 
6.3.2.3.2. 



Table 191— SCa PHY synchronization field 



Syntax 


Size 


Notes 


PHY_synchronization_field() { 






Frame number 


24 bits 




} 
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Frame number: 

Identifier assigned to the frame containing the DL-MAP message. The value shall be incremented 
by one for each frame transmitted. The value wraps around to zero when the field's maximum value 
is incremented. 

8.2.1 .9.2 DL-MAP IE formats 

The EEs of Table 193 are used in DL-MAP messages. The format for these DL-MAP messages is specified 
in Table 192. Since the location in each frame and attributes of the FCH are well-known or are deduced dur- 
ing downlink initial ranging, a data grant IE identifying the start of the FCH shall not appear in the DL-MAP. 
The attributes associated with the Fill, Gap, and End of map IEs are also well-known and shall not be 
defined in the DCD. 



Table 192— SCa DL-MAP IE format 



Syntax 


Size 


Notes 


DL-MAP JE() { 






DIUC 


4 bits 




if (DIUC = 15) { 






Extended UIUC dependent IE 


variable 


See subclauses following in 8.2. 1 .9.2. 1 


} else { 






Offset 


16 bits 




if (CID used enabled by burst profile) { 






CID 


16 bits 




}' • 






} 






} 







Offset: Offset (in units of PSs) to the start of the data burst from the start of the frame. 
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CID: Represents the assignment of the IE to a unicast, multicast, or broadcast address. The value is only 
present in an IE if the burst profile associated with the DIUC value specifies that CID usage is enabled. 



Table 1 93— SCa DIUCs 



irL name 


nil tp 




Fill 


0 


Start of allocation for uncoded QPSK zero-fill 


Data Grant 1 


1 


Starting offset of data grant 1 burst type 


Data Grant 2 


2 


Starting offset of data grant 2 burst type. 


Data Grant 3 


3 


Starting offset of data grant 3 burst type 


Data Grant 4 


4 


Starting offset of data grant 4 burst type 


Data Grant 5 


5 


Starting offset of data grant 5 burst type 


Data Grant 6 


6 


Starting offset of data grant 6 burst type 


Data Grant 7 


7 


Starting offset of data grant 7 burst type 


Data urant o 


Q 

o 


otaning onset or aaia gram o oursi type 


Data Grant 9 


9 


Starting offset of data grant 9 burst type 


Data Grant 10 


10 


Starting offset of data grant 10 burst type 


Data Grant 11 


11 


Starting offset of data grant 1 1 burst type 


Data Grant 12 


12 


Starting offset of data grant 12 burst type 


Gap 


13 


Start offset of an unallocated frame interval 


End of map 


14 


Ending offset of the previous grant. Used to 
bound the length of the last actual interval 
allocation 


Extended DIUC 


15 
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8.2.1.9.2.1 DL-MAP extended IE 

A DL-MAP IE entry with a DIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 194. A station shall ignore an extended IE entry with a Subcode value for 
which the station has no knowledge. In the case of a known subcode value but with a length field longer than 
expected, the station shall process information up to the known length and ignore the remainder of the IE. 



Table 194— SCa DL-MAP extended IE format 



Syntax 


Size 


Notes 


DL_Extended_IE() { 






Subcode 


4 bits 


0x00..0x0F 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







8.2.1.9.2.2 Channel measurement extended IE 

An extended IE with a Subcode value of 0x00 is issued by the BS to request a a channel measurement 
report (see 6.3.15). The IE includes an 8-bit Channel Nr value as shown in Table 195. The 
Channel_Measurement_IE shall be followed by the End of Map IE (DIUC=14). 



Table 195— SCa Channel measurement extended IE format 



Syntax 


Size 


Notes 


Channel_Measurement_IE() { 






Subcode 


4 bits 


CHM = 0x00 


Length 


4 bits 


Length - 5 


Channel Nr 


8 bits 


Channel number (see 8.5.1) 
Set to 0x00 for licensed bands 


CID 


16 bits 


Identifies SS to perform measurement 
Basic CID for specific SS 
Broadcast CID for all stations 


Offset 


16 bits 




} 







8.2.1.9.2.3 FCH burst profile change extended IE 

Signaling a pending change to the FCH burst profile definition is accomplished by using an extended IE 
with the subcode set to 0x01 (see Table 196). When included, this IE shall be located at or near the end of the 
DL-MAP IE list after all data grant IEs. 

When a change is to be made, the BS shall use this IE to notify all operating subscribers that a parameter 
change is imminent. Transmission of the IE shall be initiated at a sufficient interval prior to the scheduled 
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change to assure that all SS have received the notification and can prepare to implement the specified 
changes. Once initiated, the extended IE shall be included in all subsequent DL-MAP transmissions up to 
but not including the frame in which the specified parameter changes take effect. 



Table 196— SCa FCH burst profile change extended IE format 



Syntax 


Size 


Notes 


FCH_BP_Change_IE() { 






Subcode 


4 bits 


FCHBP = 0x01 


Length 


4 bits 


Length = 4 


Pilot Word Interval 


4 bits 


0 = no pilot words, 1 = 1024 symbols, 
2 = 2048 symbols, 3 = 4096 symbols, 
4-15: Reserved 


Pilot Word length 


4 bits 


Number of contiguous Unique Words 
composing a Pilot Word (1, 2 or 3) 


R=l Modulation 


4 bits 


0 = QPSK, 1 = 16-QAM 


R=3 Modulation 


4 bits 


0 = Fs:l, 1 = Fs:2, 2 = Fs:8 


Frame number 


16 bits 


Least significant 16 bits of frame 
number when specified FCH burst 
profile settings take effect 


} 







8.2.1 .9.2.4 AAS DL extended IE 

Within a frame, the switch from non-AAS to AAS-enabled traffic is marked by using an extended IE with 
the subcode set to 0x02. This IE indicates that the subsequent allocations (until the start of the uplink portion 
of the frame using TDD, and until the end of the frame using FDD) shall be for downlink AAS traffic. 



Table 197— SCa AAS DL extended IE format 



Syntax 


Size 


Notes 


AAS_IE0 { 






Subcode 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 2 


Offset 


16 bits 




} 
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8.2.1.9.2.5 Burst set delimiter extended IE 

Termination of one burst set and the start of another is specified by the inclusion of the burst set delimiter 
extended IE. This IE (subcode = 3) specifies the size of the DLBTG, which terminates the previous burst set 
as well as the preamble, unique word, pilot word, and STC settings that shall apply to the next burst set 
defined in the map. A length of two, indicates that the parameter values in force for the previous burst set 
shall remain in effect for the new burst set. In this case, only the Offset field follows the Length 
specification. 



Table 198— SCa burst set delimiter extended IE format 



Syntax 


Size 


Notes 


Burst_Set_Delimiter_IE() { 






Subcode 


4 bits 


BSD = 0x03 


Length 


4 bits 


Length = 

6 if parameters specified for a standard burst set 

7 if parameters specified for an STC burst set 

2 if parameters from last burst set are to be repeated 


Offset 


16 bits 


Offset (in PS) from start of frame to start of DLBTG 


DLBTG 


8 bits 


The time, expressed in PSs, between the end of a BS burst set 
and the beginning of the next burst set within the same MAC 
downlink frame. The minimum (and default) length of the 
DLBTG shall be at least one RxDS interval, so that 
ramp-down can occur and delay spread can clear receivers. 


Burst set type 


lbit 


0 = standard, 1 = STC 


Unique Word length 


3 bits 


Number of symbols in a Unique Word: 

0=16 symbols, 1 - 64 symbols, 2 = 256 symbols 


Preamble length 


4 bits 


Number of Unique Words in preamble (0-7) 


Preamble ramp-up 


4 bits 


Number of PSs in preamble ramp-up (0-15) 


Pilot Word interval 


4 bits 


[regular bursts, Burst set type = 0] 
(Pilot word's length in symbols included in interval). 
0 = no pilot words, 1 = 1024 symbols, 
2 = 2048 symbols, 3 = 4096 symbols, 
4-15: Reserved 

[STC-encoded bursts, Burst set type = 1] 
0=no pilot words, 

1-15 = number of paired blocks between pilot words 


Pilot Word length 


4 bits 


Number of contiguous Unique Words composing a Pilot 
Word (1,2, or 3) 


Roll-off 


4 bits 


0 = 0.15, 2 = 0.18, 2 =.25, 3-15: Reserved 
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Table 198— SCa burst set delimiter extended IE format (continued) 



Syntax 


Size 


Notes 


if (Burst Set Type == STC) { 






STC Parameters 


8 bits 


4 MSB: block length (segments are paired), in symbols 

1= 64, 2 = 128, 3 = 2jo, 4 = 312,..., / = 4UV0, o— 13. Keservea 

4 LSB: block burst profile type 

0 = CP derived from data and no UWs embedded within 
block 

1 = CP derived from data an additional UW as first payload 
data element in block 

2 = CP derived from UWs at beginning and end of segment 

3-15: Reserved 

— — ■ 1 - 


} 






} 







8.2.1.9.2.6 AAS DL preamble index extended IE 

The presence of this extended IE in a DL-MAP notifies the AAS-enabled SS identified by the specified 
basic CID value that the preamble used for future BS transmissions to the SS shall be. generated using the 
specified index value. 



Table 199— SCa AAS DL preamble index extended IE format 



Syntax 


Size 


Notes 


INDXJEO { 






Subcode 


4 bits 


INDX = 0x04 


Length 


4 bits 


Length = 3 


CID 


16 bits 


Basic CID of targeted SS 


Index 


8 bits 


0..3 


} 







8.2.1.9.2.7 Concurrent transmission extended IE 

In the DL-MAP, a BS may transmit DIUC=15 with a DL_Concurrent_IE() to specify one of a set of parallel 
downlink bursts for transmission. The extended format explicitly specifies the duration and the CID of the 
corresponding downlink burst. A preamble may precede the downlink burst specified by this IE. When 
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present, the preamble shall have the same characteristics as the burst set preamble of the current DL 
subframe. 



Table 200— SCa concurrent transmission extended IE format 



Syntax 


Size 


Notes , 


DL_ConcurrentJE() { 






Subcode 


4 bits 


CONC = 0x05 


Length 


4 bits 


Length = 7 


Preamble present 


1 bit 


0- No preamble precedes burst 

1- Preamble precedes burst 


reserved 


3 bits 


Shall be set to zero 


DIUC 


4 bits 




Offset 


16 bits 




CID 


16 bits 




Duration 


16 bits 


Duration of burst in PS 


} 







DIUC: 

A 4-bit DIUC shall be used to define the burst type associated with that burst. Burst Descriptor 
shall be included into DCD message for each DIUC used in the DL-MAP. The DIUC shall be one 
of the Data Grant (1-12) values defined in Table 193. 
Offset: 

Offset (in units of PS) to the start of the data burst from the start of the frame. 
CID: 

Identifies the target of the concurrent burst. The value may be a unicast or multicast address. When ~ 
specifically addressed, the CID shall be the Basic CID of the SS. 
Duration: 

Specifies the length of the associated burst in PS. 
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8.2.1.9.3 UL-MAP IE formats 

The IEs of Table 202 are used in UL-MAP messages. The format for these UL-MAP messages is specified 
in Table 201. 



Table 201— SCa UL-MAP IE format 



Syntax 


Size 


Notes 


UL-MAP_IE() { 






CID 


16 bits 




UIUC 


4 bits 




if (UIUC == 15) { 






Extended UIUC dependent IE 


variable 


See subclauses following in 8.2.1.9.3.1 


} else { 






Offset 


12 bits 




If (Burst set type is Subchannel or 
Modulation Type is Spread BPSK){ 






Duration 


12 bits 




If (Burst set type is Subchannel) { 






Starting subchannel 


4 bits 




Subchannel count 


4 bits 




} 






} 






. } 






} 







CID: 

Represents the assignment of the IE to a unicast, multicast, or broadcast address. When specifically 
addressed to allocate a bandwidth grant, the CID shall be the Basic CID of the SS. 
UIUC: 

A 4-bit code used to define the type of uplink access and the burst type associated with that access. 
A Burst Descriptor shall be included in an UCD message for each UIUC that is to be used in the 
UL-MAP. The UIUC shall be one of the values defined in Table 202. 
Offset: 

Indicates the start time, in units of minislots, of the burst relative to the Allocation Start Time given 
in the UL-MAP message. Consequently, the first IE shall have an offset of 0. The end of the last 
allocated burst is indicated by allocating a End of map burst (CID = 0 and UIUC = 14). The time 
instants indicated by offsets are the transmission times of the first symbol of the burst including 
preamble. 
Duration: 

For bursts associated with one of the spread BPSK modulation types or the subchannel burst set 
type, this parameter specifies the length of the associated burst in minislots. (For bursts not 
assigned one of these types in which overlapped transmissions can occur, the duration of the burst 
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is determined by the Offset appearing in the following IE entry and the offset of the current IE 
entry.) 

Starting subchannel: 

For bursts associated with the subchannel burst frame type, this parameter specifies starting sub- 
channel assigned to the transmission. 
Subchannel count: 

For bursts associated with the subchannel burst set type, this parameter specifies the number of 
adjacent subchannels assigned to the transmission. 



Table 202— SCa UL-MAP lEs 



IE name 


UIUC 


CID 


Minislot offset 




0 


N/A 


reserved 


Request 


1 


any 


Starting offset of REQ region 


Initial 
ranging 


2 


broadcast 


Starting offset of maintenance region (used in Initial 
Ranging) 


Data grant 
burst type 0 


3 


unicast 


Starting offset of Data Grant Burst Type 0 assignment 


Data grant 
burst type 1 


4 


unicast 


Starting offset of Data Grant Burst Type 1 assignment 


Data grant 
burst Type 2 


5 


unicast 


Starting offset of Data Grant Burst Type 2 assignment ! 


Data grant 
burst type 3 


6 


unicast 


Starting offset of Data Grant Burst Type 3 assignment 


Data grant 
burst type 4 


7 


unicast 


Starting offset of Data Grant Burst Type 4 assignment 


Data grant 
burst type 5 


8 


unicast 


Starting offset of Data Grant Burst Type 5 assignment 


Data grant 
burst type 6 


9 


unicast 


Starting offset of Data Grant Burst Type 6 assignment 


Data grant 
burst type 7 


10 


unicast 


Starting offset of Data Grant Burst Type 10 assignment 


Data grant 
burst type 8 


11 


unicast 


Starting offset of Data Grant Burst Type 11 assignment 


Data grant 
burst type 12 


12 


unicast 


Starting offset of Data Grant Burst Type 12 assignment 


Gap 


13 


zero 


Used to schedule gaps in transmission 


End of map 


14 


zero 


Ending offset of the previous grant. 

Used to bound the length of the last actual interval allocation. 


Extended 
UIUC 


15 


extended 
UIUC 





A BS supporting the AAS option shall allocate at the end of the uplink frame an initial ranging slot for AAS 
SS that have to initially alert the BS to their presence. This period shall be marked in the UL-MAP as Initial 
Ranging (UIUC=2), but shall be marked by an AAS initial ranging CID such that no non-AAS subscriber 
(or AAS subscriber that can decode the UL-MAP message) uses this interval for Initial Ranging. 
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8.2.1.9.3.1 UL-MAP extended IE 

A UL-MAP IE entry with a UIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 203. A station shall ignore an extended IE entry with a Subcode value for 
which the station has no knowledge. In the case of a known subcode value but with a length field longer than 
expected, the station shall process information up to the known length and ignore the remainder of the IE. 



Table 203— SCa UL-MAP extended IE format 



Syntax 


Size 


Notes 


UL_Extended_IE() { 






Subcode 


4 bits 


Ox0O..Ox0F 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







8.2.1.9.3.2 Power control extended IE 

To command a change in SS transmission power, the BS may issue an extended IE with the subcode set to 
0. The IE specifies the desired change in transmission power to be implemented by the SS. The CID in the 
UL-MAP_IE() shall be set to the Basic CID of the SS. 



Table 204 — SCa power control extended IE format 



| Syntax 


Size 


Notes 


Power_ControLIE() { 






Subcode 


4 bits 


FPC = 0x00 


Length 


4 bits 


Length - 1 


Power delta 


8 bits 


Signed integer, which expresses the 
change in power level (in 0.25 dB 
units) that the SS should apply to 
correct its current transmission power. 


} 
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8.2.1.9.3.3 AAS UL extended IE 

Within a frame, the switch from non-AAS to AAS-enabled traffic is marked by using an extended IE with 
the subcode set to 0x02. This IE indicates that the subsequent allocations up to the end of the uplink sub- 
frame shall be for AAS traffic. The CID in the UL-MAP_IE() shall be set to the broadcast CID. 



Table 205— SCa AAS UL extended IE format 



Syntax 


Size 


Notes | 


AASJJLJEO { 






Subcode 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 2 


Offset 


12 bits 




reserved 


4 bits 


Shall be set to zero 


} 







8.2.1.9.3.4 AAS UL preamble index extended IE 

The presence of this extended IE in a UL-MAP instructs the AAS-enabled SS associated with the basic CID 
value appearing in the parent IE CID field to use the AAS preamble associated with the specified index 
value for any future transmissions. This includes transmissions associated with data grants appearing later in 
the same UL-MAR 



Table 206— SCa AAS UL preamble index extended IE format 



Syntax 


Size 


Notes 


INDX JE0 { 






Subcode 


4 bits 


INDX = 0x03 


Length 


4 bits 


Length = 1 


Index 


8 bits 


0..3 


} 
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8.2.1.9.3.5 Concurrent transmission extended IE 

In the UL-MAP, a BS may transmit UIUC=15 with the UL_Concurrent_IE() to specify one of a set of paral- 
lel uplink allocations for transmission. This format explicitly specifies the duration of the corresponding 
uplink burst. 



Table 207 — SCa concurrent transmission extended IE format 



Syntax 


Size 


Notes 


UL_Concurrent_IE() { 






Subcode 


4 bits 


CONC = 0x04 


Length 


4 bits 


Length = 

4 if Burst set type is not Subchannel 

5 if Burst set type is Subchannel 


UIUC 


4 bits 




Offset 


12 bits 




Duration 


12 bits 


Duration of burst in minislots 


reserved 


4 bits 


Shall be set to zero 


if (Burst set type is subchannel) { 






Starting subchannel 


4 bits 




Subchannel count 


4 bits 




} 







UIUC: 

UIUC shall be used to define the type of uplink access and the burst type associated with that 
access. A Burst Descriptor shall be included into an UCD message for each UIUC used in the UL- 
MAR The UIUC shall be one of the values defined in Table 179 except Gap, End of map or 
Extended UIUC. 
Offset: 

Indicates the start time, in units of minislots, of the burst relative to the Allocation Start Time given 
in the UL-MAP message. 
Duration: 

Specifies the length of the associated burst in minislots. 
Starting subchannel: 

For bursts associated with the subchannel burst frame type, this parameter specifies starting sub- 
channel assigned to the transmission. Specifies the length of the associated burst in minislots. 
Subchannel count: 

For bursts associated with the subchannel burst set type, this parameter specifies the number of 
adjacent subchannels assigned to the transmission. 

8.2.1.10 Burst profile formats 

Table 208 defines the format of the Downlink^Burst^Profile, which is used in the DCD message (6.3.2.3.1). 
The Downlink_Burst_Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit DIUC. The DIUC field 
is associated with the Downlink Burst Profile and Thresholds. The DIUC value is used in the DL-MAP 
message to specify the Burst Profile to be used for a specific downlink burst. 
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Table 208 — SCa Downlink_Burst_Profile format 



Syntax 


Size 


Notes 


Downlink_Burst_Profile { 






Type=l 


8 bits 




Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


DIUC 


4 bits 




TLV encoded information 


variable 




} 







Table 209 defines the format of the Uplink_Burst_Profile, which is used in the UCD message (63.2.3.3). 
The Uplink_Burst_Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit UIUC. The UIUC field is 
associated with the Uplink Burst Profile and Thresholds. The UIUC value is used in the UL-MAP message 
to specify the Burst Profile to be used for a specific uplink burst. 



Table 209— SCa Uplink_Burst_Profile format 



Syntax 


Size 


Notes 


Uplink_Burst_Profile { 






Type=l 


8 bits 




Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


UIUC 


4 bits 




TLV encoded information 


variable 




} 
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8.2.1.11 AAS-FBCK-REQ/RSP message bodies 

The format of the AAS Feedback Request message body is shown in Table 210. 

Table 210— SCa AAS Feedback Request message body 



Syntax 


Size 


Notes 


SCa-AAS-FBCK-REQ_Message_Body() { 






Frame Number 


8 bits 




Number of Frames 


8 bits 




Feedback Request Number 


8 bits 


- 


Data Source 


2 bits 


0— Preamble of AAS transmissions 
holding data for SS 

1— AAS-indicator sequence 
2, 3 — Reserved 


Measurement Requests 


6 bits 


Bit #0 — Report relative phase offsets 
Bit #1— Report CINR mean 
Bit #2— Report CINR std dev 
Bit #3— Report RSSI mean 
Bit #4 —Report RSSI std dev 
Bit #5 — Reserved 


} 







Frame Number 

The least significant 8 bits of the frame number in which to start the measurement. 
Number Of Frames 

The number of frames over which to measure. 
Feedback Request Number 

Incremented each time an AAS-FBCK-REQ is sent to an SS. Valid values are 0-254. 
Unique counters shall be maintained for each SS. 
Data Source 

Specifies the frame entity to be measured. 
Measurement Requests 

Specifies the measurements to be performed on the indicated data s 



t source. 
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The format of the SCa A AS Feedback Response message body is shown in Table 211. 



Table 211— SCa AAS Feedback Request message body 



Syntax 


Size 


Notes 


SCa-AAS-FBCK-RSP_Message_Body() { 






I Feedback Request Number 


8 bits 




Number of Observations 


8 bits 




Data Source 


2 bits 


0 — Preamble of AAS transmis- 
sions directed at SS 

1 — AAS-indicator sequence. 
2, 3 — Reserved 


Measurements Reported 


6 bits 


Bit #0 — Relative ohase offsets 

Bit #1— CINR mean i 

Dlt ffz — L4rNK Stu Qev 

Bit #3— RSSI mean 
Bit #4— RSSI std dev 
Bit #5— Reserved 


if (Relative phase offsets reported) { 






Phase offset — antenna 1 vs 0 


5 bits 


Units of 360°/32 


Phase offset — antenna 2 vs 0 


5 bits 


Units of360°/32 


Phase offset — antenna 3 vs 0 


5 bits 


Units of360°/32 


reserved 


1 bit 


Shall be set to zero 


} 






if (CINR mean reported) 






CINR mean 


8 bits 


See 8.2.2 


if (CINR std dev reported) 






CINR std dev 


8 bits 


See 8.2.2 


if (RSSI mean reported) 






RSSI mean 


8 bits 


See 8.2.2 


if (RSSI std dev reported) { 






RSSI std dev 


8 bits 


See 8.2.2 


} 







Feedback Request Number 

Frame Request Number from the AAS-FBCK-REQ messages to which this is the response. 
A value of 255 indicates that measurements reported were not requested by the BS. 
Number of Observations 

Number of instances of the data source item contributing to the measurements reported. 
Data Source 

Specifies the frame entity that was measured. 
Measurements Reported 

Specifies the measurements performed on the indicated data source and reported in this message. 
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8.2.1.12 Baseband Pulse Shaping 

Prior to modulation, I and Q signals shall be filtered by square-root raised cosine. A roll-off factor of 
a = 0.25 shall be supported; 0.15 and 0.18 are optional, but defined settings. The ideal square-root cosine is 
defined in the frequency domain by the transfer function shown in Equation (50). 



Hif) = 



where 



0 +«) 



M</^i-«) 

(50) 



In ~ 2T s 2 ' 

/ N is the Nyquist frequency, 

T s is the modulation symbol duration, 

R s is the symbol rate. 

8.2.1.13 Quadrature modulation 

Define the quadrature modulated transmit waveform s(t) as 

(52) 

s(t) = /(/)cos(2ji/ c O-G(Osin(27t/ c ») v 
where /(») and 6(0 are the filtered baseband signals of the / and Q symbols and f c is the carrier frequency. 

8.2.1.14 Power control 

Power control shall be supported on the uplink, using both initial calibration and periodic adjustment 
procedures, and without loss of data. To support this, a BS shall be capable of making accurate power 
measurements of a received signal burst, nominally using the specifications for measurements found in 
8.2.2.2. This measurement can then be compared against a reference level, and the resulting error fed back to 
an SS in a calibration message from the MAC. 

Although its exact implementation is not specified, the power control algorithm shall be designed to respond 
power fluctuations at rates of no more than 30 dB/second and depths of at least 10 dB. Subclause 8,2.3.5 
provides recommendations on overall power control range, stepsize, and absolute accuracy in an 
implementation. 

A power control algorithm shall also account for the interaction of the RF power amplifier with different 
burst profiles. For example, when changing from the QAM modulation of one burst profile to another, 
amplifier backoff margins shall be maintained to prevent peak clipping and violation of emissions masks 
and/or excessive transmitter EVM. 
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8.2.2 Channel quality measurements 

8.2.2.1 Introduction 

RSSI and CINR signal quality measurements and associated statistics can aid in such processes as BS 
selection/assignment and burst adaptive profile selection. As channel behavior is time-variant, both mean 
and standard deviation are defined. 

The process by which RSSI measurements are taken does not necessarily require receiver demodulation 
lock; for this reason, RSSI measurements offer reasonably reliable channel strength assessments even at low 
signal levels. On the other hand, although CINR measurements require receiver lock, they provide informa- 
tion on the actual operating condition of the receiver, including interference and noise levels, and signal 
strength. 

8.2.2.2 RSSI mean and standard deviation 

When collection of RSSI measurements is mandated by the BS, an SS shall obtain an RSSI measurement 
from the downlink burst set preambles. From a succession of RSSI measurements, the SS shall derive and 
update estimates of the mean and the standard deviation of the RSSI, and report them via REP-RSP 
messages. 

Mean and standard deviation statistics shall be reported in units of dBm. To prepare such reports, statistics 
shall be quantized in 1 dB increments, ranging from -40 dBm (encoded 0x53) to -123 dBm (encoded 0x00). 
Values outside this range shall be assigned the closest extreme value within the scale. 

The method used to estimate the RSSI of a single message is left to individual implementation, but the 
relative accuracy of a single signal strength measurement, taken from a single message, shall be ± 2 dB, with 
an absolute accuracy of ± 4 dB. This shall be the case over the entire range of input RSSIs. In addition, the 
range over which these single-message measurements are measured should extend 3 dB on each side beyond 
the -40 dBm to -123 dBm limits for the final averaged statistics that are reported. 

One possible method to estimate the RSSI of a signal of interest at the antenna connector is given by 
Equation (53). 



The (linear) mean RSSI statistics (in mW), derived from a multiplicity of single messages, shall be updated 
using Equation (54). 




(53) 



where 



B is ADC precision, number of bits of ADC, 

R is ADC input resistance [Ohm], 

V c is ADC input clip level [Volts], 

G n is analog gain from antenna connector to ADC input, 

Y lor qIKh] is /I th sample at the ADC output of / or g-branch within signal k, 

N is number of samples. 
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* = ° mW (54) 

(l-a avg W[*- 1 ] + «avg«[« fc> ° 



where fc is the time index for the message (with the initial message being indexed by k = 0, the next message 
by k = 1 etc.); R/W is the RSSI in mW measured during message k; and a avg is an averaging parameter 
specified by the BS. The mean estimate in dBm shall then be derived from Equation (55). 

(55) 

£ [k] = l(Hog(|ijK5|[*)) dBm v ' 

RSSI dBm 

To solve for the standard deviation in dB, the expectation-squared statistic shall be updated using Equation 
(56), 



2 



\R[0}\ 2 * = ° (56) 



and the result applied to Equation (57). 

= 5iog(|4 S5/ [*]-(iw^ 2 |) dB (57) 



RSSI dB 



8.2.2.3 CINR mean and standard deviation 

When CINR measurements are mandated by the BS, an SS shall obtain a CINR measurement from the 
downlink burst preambles. From a succession of these measurements, the SS shall derive and update 
estimates of the mean and the standard deviation of the CINR, and report them via REP-RSP messages. 

Mean and standard deviation statistics for CINR shall be reported in units of <». To prepare such reports, 
statistics shall be quantized in 1 dB increments, ranging from a minimum of -20 dB (encoded 0x00) to a 
maximum of 37 dB (encoded 0x29). Values outside this range shall be assigned the closest extreme value 
within the scale. 

The method used to estimate the CINR of a single message is left to individual implementation but the 
relative and absolute accuracy of a CINR measurement derived from a single message shall be ± 1 dB and 
± 2 dB respectively, for all input CINRs above 0 dB. In addition, the range over which these single-packe 
measurements are measured should extend 3 dB on each side beyond the -20 dB to 37 dB limits for the final 
reported, averaged statistics. 

One possible method to estimate the CINR of a single message is by normalizing the mean-squared residual 
error of detected data symbols (and/or pilot symbols) by the average signal power using Equation (58). 

c«m - $ 

where ONR[*] is the (linear) CINR for message *; rftn] is received symbol n within message k; ^k,n] the 
corresponding detected or pilot symbol corresponding to received symbol n; 
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N-\ 

A[k] = £ \stf>nf (59) 
n = 0 

is the average signal power, which is normally kept constant within a message by action of automatic gain 
control (AGC); and 

N- 1 

E[k] = £ \r[k,n]-s[k 9 n]\ 2 . (60) 
n = 0 

The mean CINR statistic (in dB) shall be derived from a multiplicity of single messages using Equation (61) 
t CINR ^ I*] = Mog(t CINR [k]) (61) 
where 



HcinrM = 



CINR[0] k = 0 

( 1 - <* avg )|i cinr[* - 1 ] + a ayg CINR[*] k > 0 



(62) 



k is the time index for the message (with the initial message being indexed by k = 0, the next message by k = 
1, etc.); CINR/*/ is a linear measurement of CINR (derived by any mechanism that delivers the prescribed 
accuracy) for message k\ and a avg is an averaging parameter specified by the BS. 

To solve for the standard deviation, the expectation-squared statistic shall be updated using Equation (63), 



^cinrW ~" 



|CINR[0]| 2 jfc = 0 

(1 " a avg)*ciNR[*- 1] + a avg! CINR[t]| 2 k> 0 



(63) 



and the result applied to Equation (64). 

2\ 

dB (64) 



6 = 5l0gf *ciNR[*] -GlciNRt*]) 2 ) 

CINR dB v y 



8.2.3 System requirements 

8.2.3.1 Channel frequency accuracy 

RF channel frequency accuracy for an SS shall be within ± 15*10" 6 of the selected RF carrier over a 
temperature range of -40 to +65 °C operational and up to five years from the date of manufacture of the 
equipment manufacture. The frequency accuracy for a BS shall be within ± 8*10"^ of the selected RF carrier 
over an operational temperature range of -AO to +65 °C, up to ten years from the date of equipment 
manufacture. 
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8.2.3.2 Symbol rate 

For a roll-off factor of x, the nominal symbol rate, SR (in MBd/s), for an implemented channel bandwidth, 
BW (in MHz), shall be SR = (5W-0.088)/(l + a) . 

8.2.3.3 Symbol timing jitter 

The minimum-to-maximum difference of symbol timing over a period of 2 s shall be less than 2% of the 
nominal symbol period. This jitter specification shall be maintained over an operational temperature range 
of^O to +65 °C. 

8.2.3.4 Transmitter minimum SNR and EVM 

A transmitted signal shall have an SNR of no less than 40 dB at the transmit antenna feed point. The 
transmitter EVM should be no greater than 3.1%, assuming 64-QAM. 

8.2.3.5 Transmitter power level control 

An SS and BS transmitter shall provide, respectively, > 30 dB and > 20 dB of monotonic power level 
control, with a step size granularity of 1 dB. The relative accuracy of the power control mechanism for both 
SS and BS is ±25% of the control step in dB, but no more than 4 dB. (As an example, for a step size of 10 dB 
the relative accuracy is 2.5 dB). 

The power level absolute accuracy for both SS and BS transmitters shall be within ±6 dB. 

8.2.3.6 Ramp-up/down requirements 

Transmit output power shall settle to within the tolerances specified in 8.2.3.5 within 5 |xs. Transients due to 
the transmit filter impulse response shall be factored into settling time calculations. 

8.2.3.7 Spurious emissions during burst on/off transients 

A transmitter shall control spurious emissions to conform with applicable regulatory requirements. This 
includes prior to and during ramp-up, during and following ramp-down, and before and after a burst set in a 
TDM/TDMA scheme, 

8.2.3.8 Out of band spurious emissions 

Out of band spurious emissions shall conform with applicable local regulatory spectral masks. 

8.2.3.9 Receiver sensitivity 

Receiver sensitivity shall be better than the values listed below (computed at 10~ 3 uncoded BER, and a total 
of 7 dB in receiver noise figure and 3 dB implementation loss). BW is specified in MHz. 

QPSK: -93.2+ lO-log(BW) 
16-QAM: -86.2+ 10 1og(W) 
64-QAM: - 80 + 10 * log (BW) 

SNR^ assumptions (for uncoded signals at 10~ 3 BER) are the following: 

QPSK: 9.8 dB 
16-QAM: 16.8 dB 
64-QAM: 23.0 dB 
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8.2.3.10 Receiver maximum input signal 

A BS shall be capable of receiving a maximum on-channel operational signal of -40 dBm and should 
tolerate a maximum input signal of 0 dBm without damage to circuitry. An SS shall be capable of receiving 
a maximum on-channel operational signal of -20 dBm and should tolerate a maximum input signal of 0 
dBm without damage to circuitry. 

8.2.3.11 Receiver adjacent channel interference 

A system shall achieve the minimum adjacent and alternate adjacent channel interference performance as 
shown in Table 212. All measurements shall be performed uncoded. 

Table 212— Minimum adjacent and alternate adjacent channel interference performance 





At BER 1<T 3 , 

for 3 dB 
degradation 


At BER 1<T 3 , 

for 1 dB | 
degradation 


1 st adjacent 
channel interference 
i C/I 


BPSK: -12 
QPSK: -9 
16-QAM: -2 
64-QAM: +5 
256-QAM: +12 


BPSK: -8 
QPSK: -5 
16-QAM: +2 
64-QAM: +9 
256-QAM: +16 


2 nd adjacent 
channel interference 
C/I 


BPSK: -37 
QPSK: -34 
16-QAM: -27 
64-QAM: -20 
256-QAM: -13 


BPSK: -33 
QPSK: -30 
16-QAM: -22 
64-QAM: -16 
256-QAM: -9 
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8.3 WirelessMAN-OFDM PHY 



8.3.1 Introduction 

The WirelessMAN-OFDM PHY is based on OFDM modulation and designed for NLOS operation in the 
frequency bands below 1 1 GHz as per 1 .3.4. 

8.3.1.1 OFDM symbol description 



8.3.1.1.1 Time domain 



Inverse-Fourier-transforming creates the OFDM waveform; this time duration is referred to as the useful 
symbol time T b . A copy of the last T g of the useful symbol period, termed CP, is used to collect multipath, 
while maintaining the orthogonality of the tones. Figure 195 illustrates this structure. 











-< — 




T 

— 




► 

n 

► 



Figure 195 — OFDM symbol time structure 



The transmitter energy increases with the length of the guard time while the receiver energy remains the 
same (the cyclic extension is discarded), so there is a 10log(l - T g /(T b + r g ))/log(10) dB loss in E^Nq. 
The CP overhead fraction and resultant SNR loss could be reduced by increasing the FFT size, which would 
however, among other things, adversely affect the sensitivity of the system to phase noise of the oscillators. 
Using a cyclic extension, the samples required for performing the FFT at the receiver can be taken anywhere 
over the length of the extended symbol. This provides multipath immunity as well as a tolerance for symbol 
time synchronization errors. 

On initialization, an SS should search all possible values of CP until it finds the CP being used by the BS. 
The SS shall use the same CP on the uplink. Once a specific CP duration has been selected by the BS for 
operation on the downlink, it should not be changed. Changing the CP would force all the SSs to 
resynchronize to the BS. 

8.3.1 .1 .2 Frequency domain 

The frequency domain description includes the basic structure of an OFDM symbol. 

An OFDM symbol (see Figure 196) is made up from subcarriers, the number of which determines the FFT 
size used. There are three subcarrier types: 

— Data subcarriers: For data transmission 

— Pilot subcarriers: For various estimation purposes 

— Null subcarriers: No transmission at all, for guard bands, non-active subcarriers and the DC 
subcarrier. 



Copyright ©2004 IEEE. All rights reserved. 



427 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS-PART 16: 



Data Subcarriers 



DC subcarrier 



Pilot Subcarriers 




^\Guard Band 



Channel 

Figure 196— OFDM frequency description 



Guard band., 



NOTE -The example in Figure 196 shows the amplitude of the real (in-phase) component of an OFDM symbol with 
QPSK modulated data. 

The purpose of the guard bands is to enable the signal to naturally decay and create the FFT "brick Wall- 
shaping. Subcarriers are non-active only in the case of subchannelized transmission by an SS. 

Subchannelized transmission in the uplink is an option for an SS, and shall only be used if the BS signals its 
capability to decode such transmissions. 

8.3.2 OFDM symbol parameters and transmitted signal 

8.3.2.1 Primitive parameter definitions 

Four primitive parameters characterize the OFDM symbol: 

BW. This is the nominal channel bandwidth. 

' — Nut** Number of used subcarriers. 

_ it Sampling factor. This parameter, in conjunction with BW and N used determines the subcarrier 
spacing, and the useful symbol time. Required values of this parameter are specified in 8.3.2.4 

— G. This is the ratio of CP time to "useful" time. Required values of this parameter are specified in 
8.3.2.4. 

8.3.2.2 Derived parameter definitions 

The following parameters are defined in terms of the primitive parameters of 8.3.2.1 . 

— N FFT Smallest power of two greater than N med 

— Sampling Frequency: F s = floor (n • bw/8000) x 8000 

— Subcarrier spacing: A/= FJ N FFT 

— Useful symbol time: T b = l/A/ 

— CP Time: T g - G T b 

— OFDM Symbol Time: T s = T b + T g 

— Sampling time: T b /N FFT 
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8.3.2.3 Transmitted signal 

Equation (65) specifies the transmitted signal voltage to the antenna, as a function of time, (luring any 
OFDM symbol. 



s(t) = Re 



j2Kf c t 



**0 



j2nkAf(t-T g 



(65) 



where 
t 



is the time, elapsed since the beginning of the subject OFDM symbol, with 0 < t < T s , 
is a complex number; the data to be transmitted on the subcarrier whose frequency offset index is 
k, during the subject OFDM symbol. It specifies a point in a QAM constellation. In subchannelized 
transmissions, c k is zero for all unallocated subcarriers. 



8.3.2.4 Parameters of transmitted signal 

The parameters of the transmitted OFDM signal, transmitted as in 83.2.3, are given in Table 213. 



Table 213— OFDM symbol parameters 



Parameter 


Value 


N FFT 


256 


N used 


200 


n 


For channel bandwidths that are a 
multiple of 1.75 MHz then n = 8/7 
else for channel bandwidths that are a 
multiple of 1.5 MHz then n = 86/75 
else for channel bandwidths that are a 
multiple of 1.25 MHz then n = 144/125 
else for channel bandwidths that are a 
multiple of 2.75 MHz then n = 316/275 
else for channel bandwidths that are a 
multiple of 2.0 MHz then n = 57/50 
else for channel bandwidths not 
otherwise specified then n = 8/7 


G 


1/4, 1/8, 1/16, 1/32 


Number Cf lower frequency guard subcarriers 


28 


Number of higher frequency guard subcarriers 


27 
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Table 21 3— OFDM symbol parameters (continued) 



Parameter 


Value 


Frequency offset indices of guard subcarriers 


-128 -127... -101 
+101,+102,...,127 


Frequency offset indices of pilot carriers 


-88-63,-38,-13,13,38,63,88 


Subchannel Index: 

( ObOOOOl: 

j ObOOOlO: 

/ObOOlOO: 0b00011: 
( ObOOlOl: 

1 ObOOllO: 

/ ObOlOOO: { 1 ObOOlll: 

[ ObOlOOl: 

f ObOlOlO: 

V 0b01100: 1 0b01011: 
[ ObOllOl: 

1 ObOlllO: 

OblOOOO: < 1 0b011ll: 

f OblOOOl: 

f OblOOlO: 

I OblOOll: 

/OblOlOO: oblOlOl: 
* OblOllO: 

V QbllOOO: < 1 0bl0111: 
1 f Obi 1001: 

i obiioio. obnoil: 

WllOO: 0M1101: 
1 ObllllO: 

1 Oblllll: 


Allocated Frequency offset indices of 
subcarriers: 

{-100:-98, -37:-35, 1:3, 64:66} 
{-38} 

{ _97:-95, -34:-32, 4:6, 67:69} 
{ _94:-92, -31:-29, 7:9, 70:72} 
{13} 

{-91:-89, -28:-26, 10:12, 73:75} 
{ _87:-85, -50:^8, 14:16,51:53} 
{-88} 

{-84,-82, -47:^t5, 17: 19, 54:56} 
{_81:-79, -44:^12, 20:22, 57:59} 
{63} 

{_78:-76, -41:-39, 23:25, 60:62} 
{_75:-73, _12:-10, 26:28, 89:91 } 
{-13} 

{-72:-70, -9: -7, 29:31,92:94} 
{ _69:_67, -6: -4,32:34, 95:97} 
{38} 

{_66:-64, -3: -1, 35:37, 98:100} 
{-62:-60, -25:-23, 39:41, 76:78} 
{-63} 

{-59:-57, -22:-20, 42:44, 79:81 } 
{-56:-54, -19:-17, 45:47, 82:84} 
{88} 

{-53:-51, -16:-14, 48:50, 85:87} 

Note that pilot subcarriers are allocated 
only if two or more subchannels are 
allocated. 



8.3.3 Channel coding 

Channel coding is composed of three steps: randomizer, FEC, and interleaving. They shall be applied in this 
order at transmission. The complementary operations shall be applied in reverse order at reception. 

8.3.3.1 Randomization 

Data randomization is performed on each burst of data on the downlink and uplink. The randomization is 
performed on each allocation (downlink or uplink), which means that for each allocation of a data block 
(subchannels on the frequency domain and OFDM symbols on the time domain) the randomizer shall be 
used independently. If the amount of data to transmit does not fit exactly the amount of data allocated, 
padding of OxFF ("1" only) shall be added to the end of the transmission block. For RS-CC and CC encoded 
data (see 8.3.3.2.1), padding will be added to the end of the transmission block, up to the amount of data 
allocated minus one byte, which shall be reserved for the introduction of a 0x00 tail byte by the FEC. For 
BTC (8.3.3.2.2) and CTC (8.3.3.2.3), if implemented, padding will be added to the end of the transmission 
block, up to the amount of data allocated. 
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The shift-register of the randomizer shall be initialized for each new allocation. 

The PRBS generator shall be l +x l4 + x ]5 as shown in Figure 197. Each data byte to be transmitted shall 
enter sequentially into the randomizer, MSB first. Preambles are not randomized. The seed value shall be 
used to calculate the randomization bits, which are combined in an XOR operation with the serialized bit 
stream of each burst. The randomizer sequence is applied only to information bits. 

MSB LSB 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 




i in 




Figure 197— PRBS for data randomization 

The bits issued from the randomizer shall be applied to the encoder. 

On the downlink, the randomizer shall be re-initialized at the start of each frame with the sequence: 10 010 
1010000000. The randomizer shall not be reset at the start of burst #1 . At the start of subsequent bursts, 
the randomizer shall be initialized with the vector shown in Figure 198. The frame number used for 
initialization refers to the frame in which the downlink burst is transmitted. 



BSID 



DlUC 



Frame number 



MSB 





h 




bo 



b 3 


b 2 


h 


bo 



IjUj(ZZZZ 



LSB 



MSB 


b H 


b l3 


bn 


bn 


1 


1 


»8 


h 


b 6 


b 5 


1 


h 


b 2 


bi 


bo 



LSB 



OFDM randomizer DL initialization vector 



Figure 198— OFDM randomizer downlink initialization vector for burst #2...N 

On the uplink, the randomizer is initialized with the vector shown in Figure 199. The frame number used for 
initialization is that of the frame in which the UL map that specifies the uplink burst was transmitted. 



BSID 



MSB 



£>3 b 2 bi b 0 



MSB 



7 14 



13 °12 °\\ 



UlUC 



Frame number 



^3 ^2 b\ bQ &3 &2 



h &2 b \ b o 



LSB 



OFDM randomizer UL initialization vector 
Figure 199— OFDM randomizer uplink initialization vector 



Copyright ©2004 IEEE. All rights reserved. 



431 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS-PART 16: 



8.3.3.2 FEC 

An FEC, consisting of the concatenation of a Reed-Solomon outer code and a rate-compatible convolutional 
inner code, shall be supported on both uplink and downlink. Support of BTC and CTC is optional. The 
Reed-Solomon-Convolutional coding rate 1/2 shall always be used as the coding mode when requesting 
access to the network (except in subchannelization modes, which uses only convolutional coding 1/2) and in 
the FCH burst. 

The encoding is performed by first passing the data in block format through the RS encoder and then passing 
it through a zero-terminating convolutional encoder. 

8.3.3.2.1 Concatenated Reed-Solomon-convolutional code (RS-CC) 

The Reed-Solomon encoding shall be derived from a systematic RS (N = 255, K = 239, T = 8) code using 
GF(2 8 ), 

where 

N is the number of overall bytes after encoding, 

K is the number of data bytes before encoding, 

T is the number of data bytes which can be corrected. 

The following polynomials are used for the systematic code: 

Code Generator Polynomial: g{x) = (x + X 0 )(x + X l )(x + X 2 )...(x + X 2T - { ),X = 02 HEX (66) 

Field Generator Polynomial: p(x) = * 8 + x 4 + x 3 + x 2 + 1 ( 67 ) 

This code is shortened and punctured to enable variable block sizes and variable error-correction capability. 
When a block is shortened to K data bytes, add 239-/T zero bytes as a prefix. After encoding discard these 
239-tf zero bytes. When a codeword is punctured to permit T bytes to be corrected, only the first IT of the 
total 16 parity bytes shall be employed. The bit/byte conversion shall be MSB first. 

Each RS block is encoded by the binary convolutional encoder, which shall have native rate of 1/2, a 
constraint length equal to 7, and shall use the generator polynomials codes shown in Equation (68) to derive 
its two code bits: 

G x = m 0CT FOR X (68) 

G 9 = 133 rtrT FOR Y 
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The generator is depicted in Figure 200. 



^ X output 




I ► Y output 

Figure 200 — Convolutional encoder of rate 1/2 



Puncturing patterns and serialization order that shall be used to realize different code rates are defined in 
Table 214. In the table, "1" means a transmitted bit and "0" denotes a removed bit, whereas X and Y are in 
reference to Figure 200. 

Table 214— The inner convolutional code with puncturing configuration 





Code rates 


Rate 


1/2 


2/3 


3/4 


5/6 


^free 


10 


6 


5 


4 


X 


1 


10 


101 


10101 


Y 


1 


11 


110 


11010 


XY 


X { Y X 


X X Y X Y 2 







The RS-CC rate 1/2 shall always be used as the coding mode when requesting access to the network. 

The encoding is performed by first passing the data in block format through the RS encoder and then passing 
it through a convolutional encoder. A single 0x00 tail byte is appended to the end of each burst. This tail byte 
shall be appended after randomization. In the RS encoder, the redundant bits are sent before the input bits, 
keeping the 0x00 tail byte at the end of the allocation. When the total number of data bits in a burst is not an 
integer number of bytes, zero pad bits are added after the zero tail bits. The zero pad bits are not randomized. 
Note that this situation can occur only in subchannelization. In this case, the RS encoding is not employed. 

Table 215 gives the block sizes and the code rates used for the different modulations and code rates. As 
64-QAM is optional for license-exempt bands, the codes for this modulation shall only be implemented if 
the modulation is implemented. 
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Table 215— Mandatory channel coding per modulation 



Modulation 


Uncoded block size 
(bytes) 


Coded block 
size 
(bytes) 


Overall coding rate 


RS code 


CC code rate 


BPSK 


12 


24 


1/2 


(12,12,0) 


1/2 


QPSK 


24 


48 


1/2 


(32,24,4) 


2/3 


QPSK 


36 


48 


3/4 


(40,36,2) 


5/6 


16-QAM 


48 


96 


1/2 


(64,48,8) 


2/3 


16-QAM 


72 


96 


3/4 


(80,72,4) 


5/6 ! 


64-QAM 


96 


144 


2/3 


(108,96,6) 


3/4 


64-QAM 


108 


144 


3/4 


(120,108,6) 


5/6 



When subchannelization is applied in the uplink, the FEC shall bypass the RS encoder and use the Overall 
Coding Rate as indicated in Table 215 as CC Code Rate. The Uncoded Block Size and Coded Block size 
may be computed by multiplying the values listed in Table 215 by the number of allocated subchannels 
divided by 16. 

In the case of BPSK modulation, the RS encoder should be bypassed. 
8.3.3.2.2 Block Turbo Coding (optional) 

BTC is based on the product of two simple component codes, which are binary extended Hamming codes or 
parity check codes from the set depicted in Table 216. 



Table 216— BTC component codes 



Component code (n,k) 


Code type 


(64,57) 


Extended Hamming code 


(32,26) 


Extended Hamming code 


(16,11) 


Extended Hamming code 


(64,63) 


Parity check code 


(32,31) 


Parity check code 


(16,15) 


Parity check code 


(8,7) 


Parity check code 
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Table 217 specifies the generator polynomials for the Hamming codes. To create extended Hamming codes, 
an overall even parity check bit is added at the end of each code word. 

Table 217— OFDM Hamming code generator polynomials 



n' 




Generator polynomial 


1 


4 


x\x x +\ 


15 


11 


X*+X x +\ 


31 


26 


x 5 +x 2 +\ 


63 


57 


x 6 +x+\ 



The component codes are used in a two-dimensional matrix form, which is depicted in Figure 201. The k x 
information bits in the rows are encoded into n x bits, by using the component block (n v k x ) code specified 
for the respective composite code. After encoding the rows, the columns are encoded using a block code (n^ 
ky), where the check bits of the first code are also encoded. The overall block size of such a product code is 
n = n x x n y , the total number of information bits k = k x x ky and the code rate is R = R x x R y , where 
Rl = k t ln i , i = x, y. The Hamming distance of the product code is d = d x X d y . Data bit ordering for the 
composite BTC matrix is defined such that the first bit in the first row is the LSB, and the last data bit in the 
last data row is the MSB. 

Transmission of the block over the channel shall occur in a linear fashion, with all bits of the first row 
transmitted left to right followed by the second row, and so on. 

To match a required packet size, BTCs may be shortened by removing symbols from the BTC array. In the 
two-dimensional case, rows, columns, or parts thereof can be removed until the appropriate size is reached. 
There are three steps in the process of shortening product codes: 

Step 1) Remove I x rows and I y columns from the two-dimensional code. This is equivalent to 
shortening the constituent codes that make up the product code. 

Step 2) Remove B individual bits from the first row of the two-dimensional code starting with the 
LSB. 

Step 3) Use if the. product code specified from Step 1) and Step 2) has a non-integral number of 
data bytes. In this case, the Q leftover LSB are zero-filled by the encoder. After decoding 
at the receive end, the decoder shall strip off these unused bits and only the specified data 
payload is passed to the next higher level in the PHY. 

The same process is used for shortening the last code word in a message where the available data bytes do 
not fill the available data bytes in a code block. 

These three processes of code shortening are depicted in Figure 201. In the first two-dimensional BTC, a 
nonshortened product code is shown. By comparison, a shortened BTC is shown in the adjacent two- 
dimensional array. The new coded block length of the code is (n x - I x )(n y - I y ) -B. The corresponding 
information length is given as (k x - I x )(k y - I y ) - B - Q. Consequently, the code rate is given by 
Equation (69). 

R . %'*W- B -* . (69) 
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Figure 201— BTC and shortened BTC structure 

Table 218 gives the block sizes, code rates, channel efficiency, and code parameters for the different 
modulation and coding schemes. As 64-QAM is optional for license-exempt bands, the codes for this 
modulation shall only be implemented if the modulation is implemented. 



Table 218— Optional BTC channel coding per modulation 



Modulation 


Data 
block size 
(bytes) 


Coded 
block size 
(bytes) 


Overall 
code 
rate 


Efficiency 
(bit/s/Hz) 


Constituent 
codes (rtf, 
kj(n y k y ) 


Code parameter 


QPSK 


23 


48 


-1/2 


1.0 . 


(32,26)(16,11) 


7^=4, I y =2, 5=8, Q=6 


QPSK 


35 


48 


-3/4 


1.5 


(32,26)(16,15) 


4=0, 7^=4, 5=0, Q=6 


16-QAM 


58 


96 


-3/5 


2.4 


(32,26)(32,26) 


7,=0, 7^=8, 5=0, Q=4 


16-QAM 


77 


96 


-4/5 


3.3 


(64,57)(16,15) 


7,=7, 7 y =2, £=30, <2=4 


64-QAM 


96 


144 


-2/3 


3.8 


(64,63X32,26) 


7^=3,7^13,5=7,(2=5 


64-QAM 


120 


144 


-5/6 


5.0 


(32,31)(64,57) 


7^13, / v =3, 5=7,2=5 



When subchannelization is used, the coding block size is limited to blocks at least 96 bits in length, 
number of bits is calculated as shown in Equation (70). 



where 

is number of bits for 16-subchannel (full) mode, 
is number of active subchannels (1-16). 



N Jull 
N Sub 
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Table 219— Optional BTC channel coding with subchannelization 



Coded bits 


Approximate Rate 


Constituent code 


Code parameter 


96 


1/2 


(8,7), (32,26) 


I x =4 y I y =8, 5=0, Q=6 


3/4 


(16,15), (16,15) 


l x =6, I y =6, fl=4, Q=5 


144 


3/5 


(16,15), (16,11) 


I x =l, I y =0, B=0> Q=0 


5/6 


(16,15), (16,15) 


I x =4 y I y =4, 5=0, Q=\ 


192 


3/8 


(16,11), (16,11) 


I x =2 y I y =2, J5=4, 2=5 


2/3 


(8,7), (32,26) 


l x =2 y I y =0, 5=0, Q=2 


5/6 


(16,15), (16,15) 


I x =2 y I y =2, 5=4, Q=5 


288 


1/2 


(16,11), (32,26) 


I x =0, I y =14, 5=0, Q=4 


3/4 


(16,15), (32,26) 


I x =l, I y =0, 5=0, Q=0 


384 


1/2 


(16,11), (32,26) 


I x =0, I y =8, 5=0, Q=6 


3/4 


(16,15), (32,26) 


I x =4, I y =0, 5=0, Q=6 


576 


1/2 


(32,26), (32,26) 


7 X =8, I y =8, 5=0, Q=4 


3/4 


(16,15), (64,57) 


I x =7, I y =0, 5=0, Q=0 


768 


3/5 


(32,26), (32,26) 


I x =4, I y =4, 5=16, Q=4 


4/5 


(64,57), (16,15) 


I x =6 y I y =2, 5=44, Q=3 


1152 


2/3 


(64,57), (32,26) 


7^=28, I y =0, 5=0, Q=2 


5/6 


(32,31), (64,57) 


7 x =13,I y =3, 5=7, Q=5 



8.3.3.2.3 Convolutional Turbo Codes (optional) 
8.3.3.2.3.1 CTC encoder 

The Convolutional Turbo Code encoder, including its constituent encoder, is depicted in Figure 202. It uses 
a double binary Circular Recursive Systematic Convolutional code. The bits of the data to be encoded are 
alternately fed to A and 5, starting with the MSB of the first byte being fed to A. The encoder is fed by blocks 
of k bits or N couples (k = 2xAf bits). For all the frame sizes, A: is a multiple of 8 and N is a multiple of 4. N 
shall be limited to: 8 < N/4 < 1024 . For subchannelization mode, the coding block size is limited to blocks 
at least 48 bits in length, and no more than 1024 bits in length. In addition, k cannot be a multiple of 7. 

The polynomials defining the connections are described in octal and symbol notations as follows: 

— For the feedback branch: OxB, equivalently 1 + D + D 3 (in symbolic notation) 

— For the Y parity bit: OxD, equivalently 1 + D 2 + D 3 
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Figure 202— CTC encoder 
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First, the encoder (after initialization by the circulation state Sc x , see 8.3.3.2.3.3) is fed the sequence in the 
natural order (position 1) with the incremental address i = 0 .. N-\. This first encoding is called C x encoding. 
Then the encoder (after initialization by the circulation state 5c 2 , see 8.3.3.2.3.3) is fed by the interleaved 
sequence (switch in position 2) with incremental address; = 0, ... AM. This second encoding is called C 2 
encoding. 

The order that the encoded bit shall be fed into the interleaver (8.3.3.3) is as follows: 
where M is the number of parity bits. 

Table 220 gives the block sizes, code rates, channel efficiency, and code parameters for the different 
modulation and coding schemes. As 64-QAM is optional for license-exempt bands, the codes for this 
modulation shall only be implemented if the modulation is- implemented. 

Table 220— Optional CTC channel coding per modulation 



Modulation 


N 


Overall 
code 
rate 




QPSK 


6xN sub 


1/2 


7 


QPSK 


ZxN sub 


2/3 


11 


QPSK 


^sub ! 


3/4 


17 


16-QAM 


\2xN sub 


1/2 


11 
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Table 220 — Optional CTC channel coding per modulation (continued) 



Modulation 


N 


Overall 
code 
rate 




16-QAM 




3/4 


13 


64-QAM 




2/3 


17 


64-QAM 




3/4 


17 



In Table 220, N sub denotes the number of subchannels of the allocation in which the encoded data will be 
transmitted. The data block size (in bytes per OFDM symbol) may be calculated as A74. Further, P x equals 
3N/4. 

8.3.3.2.3.2 CTC Interleaver 

The interleaver requires the parameters P 0 , shown in Table 220. 
The two-step interleaver shall be performed by: 

Step 1: Switch alternate couples 

for ; = 1...N 

if (j mod2 ==0) let (BA) = (A,B) (i.e., switch the couple) 
Step IxPfi) 

The function PjQ) provides the interleaved address i of the consider couple j. 

for j = I...N 

switch 7mod4 : 

case 0 or 1: i = (/> 0 -j + i)^ 
case 2: i = (P 0 j + 1 +*/4) m( ^ 
case 3: i = (P 0 j + \ + N/2 + P l ) modN 

8.3.3.2.3.3 Determination of CTC circulation states 

The state of the encoder is denoted S ( 0 < S = 7) with S the value read binary (left to right) out of the 
constituent encoder memory (see Figure 202). The circulation states 5 cl and S c2 are determined by the 
following operations: 

Step 1) Initialize the encoder with state 0. Encode the sequence in the natural order for the 
determination of 5 cl or in the interleaved order for determination of S c2 . In both cases, the 
final state of the encoder is 5 0 ^_i; 

Step 2) According to the length N of the sequence, use Table 221 to find 5 cl or 5 c2 . 
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Table 221— Circulation state lookup table (S c ) 



N mod 7 


S 0N-i ; 


0 


1 


2 


3 


4 


5 


6 


7 


1 


0 


6 


4 


2 


7 


1 


3 


5 


2 


0 


3 


7 


4 


5 


6 


2 


1 


3 


0 


5 


3 


6 


2 


7 


1 


4 


4 


0 


4 


1 


5 


6 


2 


7 


3 


5 


0 


2 


5 


7 


1 


3 


4 


6 


6 


0 


7 


6 


1 


3 


4 


5 


2 



8.3.3.2.3.4 CTC puncturing 

The three code-rates are achieved through selectively deleting the parity bits (puncturing). The puncturing 
patterns are identical for both codes C\ and 



Table 222— CTC puncturing (S c ) 



Rate 


Y 




0 


1 


2 


3 


4 


5 


1/2 


1 


1 










2/3 


1 


0 


1 


0 






3/4 


1 


0 


0 


1 


0 


0 



8.3.3.3 Interleaving 

All encoded data bits shall be interleaved by a block interleaver with a block size corresponding to the 
number of coded bits per the allocated subchannels per OFDM symbol, Af cbps . The interleaver is defined by 
a two step permutation. The first ensures that adjacent coded bits are mapped onto nonadjacent subcarriers. 
The second permutation insures that adjacent coded bits are mapped alternately onto less or more significant 
bits of the constellation, thus avoiding long runs of lowly reliable bits. 

Let N cpc be the number of coded bits per subcarrier, i.e., 1, 2, 4 or 6 for BPSK, QPSK, 16-QAM, or 64- 
QAM, respectively. Let s = ceil(N cv J2). Within a block of JV cbps bits at transmission, let k be the index of the 
coded bit before the first permutation; m k be the index of that coded bit after the first and before the second 
permutation; and let j k be the index after the second permutation, just prior to modulation mapping. 

The first permutation is defined by Equation (71): 

>n k =W cbps /\2)-k modl2 +floor(k/\2) k = 0, 1, * cbps - 1 (71) 
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The second permutation is defined by Equation (72): 

j k = * // 0 <>r(m fc /5) + (/H^^ k = 0, 1, ...,tf cbps - 1 (72) 

The de-interleaver, which performs the inverse operation, is also defined by two permutations. Within a 
received block of N cbps bits, let j be the index of a received bit before the first permutation; nij be the index 
of that bit after the first and before the second permutation; and let kj be the index of that bit after the second 
permutation, just prior to delivering the block to the decoder. 

The first permutation is defined by Equation (73): 

mj = s floorU/s) + (j +/W(12 ' j/^ s )) mod{s) j = 0, 1, ;V cbps - 1 (73) 

The second permutation is defined by Equation (74): 

kj = \2m r {N c ^-\)floor{\2m/N c ^) j = 0, 1, * cbps - 1 (74). 

The first permutation in the de-interleaver is the inverse of the second permutation in the interleaver, and 
conversely. 

Table 223 shows the bit interleaver sizes as a function of modulation and coding. 



Table 223— Block sizes of the Bit Interleaver 





Default 
(16 

subchannels) 


8 

subchannels 


4 

subchannels 


2 

subchannels 


1 

subchannel 




N cbps 


BPSK 


192 


96 


48 


24 


12 


QPSK 


384 


192 


96 


48 


24 


16-QAM 


768 


384 


192 


96 


48 


64-QAM 


1152 


576 


288 


144 


72 



The first bit out of the interleaver shall map to the MSB in the constellation. 
8.3.3.4 Modulation 
8.3.3.4.1 Data modulation 

After bit interleaving, the data bits are entered serially to the constellation mapper. BPSK, Gray-mapped 
QPSK, 16-QAM, and 64-QAM as shown in Figure 203 shall be supported, whereas the support of 64-QAM 
is optional for license-exempt bands. The constellations (as shown in Figure 203) shall be normalized by 
multiplying the constellation point with the indicated factor c to achieve equal average power. For each 
modulation, bp denotes the LSB. 

Per-allocation adaptive modulation and coding shall be supported in the downlink. The uplink shall support 
different modulation schemes for each SS based on the MAC burst configuration messages coming from the 
BS. Complete description of the MAC/PHY support of adaptive modulation and coding is provided in 6.3.7. 
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Figure 203— BPSK, QPSK, 16-QAM, and 64-QAM constellations 



The constellation-mapped data shall be subsequently modulated onto all allocated data subcarriers in order 
of increasing frequency offset index. The first symbol out of the data constellation mapping shall be 
modulated onto the allocated subcarrier with the lowest frequency offset index. 
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8.3.3.4.2 Pilot modulation 

Pilot subcarriers shall be inserted into each data burst in order to constitute the Symbol and they shall be 
modulated according to their carrier location within the OFDM symbol. The PRBS generator depicted here- 
after shall be used to produce a sequence, w k . The polynomial for the PRBS generator shall be X* 1 + X 9 + 1. 



MSB 



LSB 



Initialization 


DL: 1 


1 


1 


1 


1 


1 


1 


1 
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1 


1 


Sequences 


UL: 1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


1 
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2 
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Figure 204— PRBS for pilot modulation 



The value of the pilot modulation for OFDM symbol k is derived from w k . On the downlink the index k 
represents the symbol index relative to the beginning of the downlink subframe. On the uplink the index k 
represents the symbol index relative to the beginning of the burst. On both uplink and downlink, the first 
symbol of the preamble is denoted by k = 0. The initialization sequences that shall be used on the downlink 
and uplink are shown in Figure 204. On the downlink, this shall result in the sequence 
11111111111000000000110... where the third 1, i.e., w 2 = 1, shall be used in the first OFDM downlink 
symbol following the frame preamble. For each pilot (indicated by frequency offset index), the BPSK 
modulation shall be derived as shown in Equation (75) and Equation (76). 



DL: 



C _88 - C -1<A — C < 



-38 = c 63 = c 88 = l ~ 2w k and c_ 63 = c_ 13 = c I3 = c 38 = \-2w k 



UL: c^ 8 = c_ 38 = c n = c 38 = c 63 = c 88 = \-2w k and c_ 63 = c_ 13 = \-2w k 



(75) 
(76) 



8.3.3.4.3 Rate ID encodings 



RateJDs, which indicate modulation and coding to be used in the first downlink burst immediately 
following the FCH, are shown in Table 224. The Rate_ID encoding is static and cannot be changed during 
system operation. 



Table 224— OFDM Rate ID encodings 



RateJD 


Modulation 
RS-CCrate 


0 


BPSK 1/2 


1 


QPSK 1/2 


2 


QPSK 3/4 


3 


16-QAM 1/2 


4 


16-QAM 3/4 
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Table 224— OFDM Rate ID encodings (continued) 



RateJD 


Modulation 
RS-CC rate 


5 


64-QAM 2/3 


6 


64-QAM 3/4 1 


7-15 


reserved 



8.3.3.5 Example OFDM uplink RS-CC encoding 

To illustrate the use of the RS-CC encoding, three examples are provided, each of one burst of OFDM uplink 
data, illustrating each process from randomization through subcarrier modulation. 

8.3.3.5.1 Full bandwidth (16 subchannels) 

Modulation Mode: QPSK, rate 3/4, Symbol Number within burst: 1, UIUC: 7, BSID: 1, Frame Number 1 
(decimal values) 

Input Data (Hex) 

45 29 C4 79 AD OF 55 28 AD 87 B5 76 1 A 9C 80 50 45 IB 9F D9 2A 88 95 EB AE B5 2E 03 4F 09 
14 69 58 OA 5D 

Randomized Data (Hex) 

D4 BA Al 12 F2 74 96 30 27 D4 88 9C 96 E3 A9 52 B3 15 AB FD 92 53 07 32 CO 62 48 F0 19 22 
E0 91 62 1AC1 

Reed-Solomon encoded Data (Hex) 

49 31 40 BF D4 BA Al 12 F2 74 96 30 27 D4 88 9C 96 E3 A9 52 B3 15 AB FD 92 53 07 32 CO 62 
48 F0 19 22 E0 91 62 1 A CI 00 

Convolutionally Encoded Data (Hex) 

3A 5E E7 AE 49 9E 6F 1C 6F CI 28 BC BD AB 57 CD BC CD E3 A7 92 CA 92 C2 4D BC 8D 78 
32 FB BF DF 23 ED 8A 94 16 27 A5 65 CF 7D 16 7A 45 B8 09 CC 

Interleaved Data (Hex) 

77 FA 4F 17 4E 3E E6 70 E8 CD 3F 76 90 C4 2C DB F9 B7 FB 43 6C Fl 9A BD ED OA 1C D8 IB 
EC 9B 30 15 BA DA 31 F5 50 49 7D 56 ED B4 88 CC 72 FC 5C 

Subcarrier Mapping (frequency offset index: I value Q value) 

-100: 1 -1, -99: -1 -1, -98: 1 -1, -97: -1 -1, -96: -1 -1, -95: -1 -1, -94: -1 1, -93: -1 1, -92: 1 -1, -91: 1 
1, -90: -1 -1, -89: -1 -1, -88:pilot= 1 0, -87: 1 1, -86: 1 -1, -85: 1 -1, -84: -1 -1, -83: 1 -1, -82: 1 1, -81: 
-1 -1, -80: -1 1, -79: 1 1, -78: -1 -1, -77: -1 -1, -76: -1 1, -75: -1 -1, -74: -1 1, -73: 1 -1, -72: -1 1,-71: 
1 -1, -70: -1 -1, -69: 1 1, -68: 1 1, -67: -1 -1, -66: -1 1, -65: -1 1, -64: 1 1, -63:pilot= -1 0, -62: -1 -1, - 
61: 1 1, -60: -1 -1, -59: 1 -1, -58: 1 1, -57: -1 -1, -56: -1 -1, -55: -1 -1, -54: 1 -1, -53: -1 -1, -52: 1 -1, 
-51: -1 1, -50: -1 1, -49: 1 -1, -48: 1 1, -47: 1 1, -46: -1 -1, -45: 1 1, -44: 1 -1, -43: 1 1, -42: 1 1, 
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-41: -1 1, -40: -1 -1,-39: 1 1, -38:pilot= 1 0, -37: -1 -1,-36: 1 -l,-35:-l 1, -34: -1 -l,-33:-l -1,-32: 
-1 -1, -31: -1 1, -30: 1 -1, -29: -1 1, -28: -1 -1, -27: 1 -1, -26: -1 -1, -25: -1 -1, -24: -1 -1, -23: -1 1, 
-22: -1 -1,-21: 1 -1,-20: 1 1,-19: 1 1,-18: -1 -1,-17: 1 -1,-16:-1 1, -15: -1 -1,-14: 1 1, -13:pilot= - 
1 0, -12: -1 -1,-11: -1 -1,-10: 1 1,-9: 1 -1,-8: -1 1,-7: 1 -l,-6:-l 1,-5: -1 1,-4: -1 l,-3:-l -1,-2: - 
1 -1,-1: 1 -1,0:0 0, 1:-1 -1, 2: -1 1,3:-1 -1,4: 1 -1,5: 1 1,6: 1 1, 7: -1 1.8: -1 1,9: 1 1, 10: 1 -1, 
11: -1 -1, 12: 1 1, 13:piIot= 1 0, 14: -1 -1, 15: 1 -1, 16: -1 1, 17: 1 1, 18: 1 1, 19: 1 -1, 20: -1 1, 21: -1 
-1,22:-1 -1,23: -1 1.24: -1 -1,25: 1 1,26: -1 1,27: 1 -1,28:-1 1, 29: -1 -1,30: 1 1,31:-1 -1,32: 1 
1,33:1 1,34:1 1, 35: 1 -1, 36: 1 -1, 37: 1 -1, 38:pilot= 1 0, 39: -1 1, 40: -1 -1, 41: -1 1,42: -1 1,43: 
-1 -1,44: 1 -1,45: *1 1,46: -1 1,47: 1 1,48: -1 -1,49: 1 1,50: 1 -1,51: -1 -1,52:-1 -1,53: 1 -1,54: 
1 -1,55: 1 -1,56: 1 -1,57: 1 1,58: 1 1,59: 1 -1,60: 1 1, 61: -1 1,62: 1 -l,63:pilot= 1 0,64: 1 -1,65: 
-1 -1, 66: -1 -1, 67: 1 -1, 68: 1 -1, 69: 1 -1, 70: 1 -1, 71: -1 1, 72: -1 -1, 73: -1 1, 74: -1 -1, 75: 1 -1, 
76: -1 1, 77: -1 -1, 78: 1 -1, 79: 1 1, 80: -1 1, 81: 1 1, 82: -1 1, 83: 1 1, 84: -1 -1, 85: 1 1, 86: -1 -1, 87: 
1 1, 88:pilot= 1 0, 89: 1 -1, 90: -1 -1, 91: 1 1, 92: -1 1, 93: -1 -1, 94: -1 -1, 95: -1 -1, 96: 1 1, 97: 1 -1, 
98: 1 -1, 99: -1 -1, 100: 1 1 

Note that the above QPSK values (all values with exception of the BPSK pilots) are to be normalized with a 
factor 1 /J2 as indicated in Figure 203. 

8.3.3.5.2 Subchannelization (2 subchannels) 

Modulation Mode: 16-QAM, rate 3/4, Symbol Numbers within burst: 1-3, UIUC: 7, BSID: 1, Frame 
Number: 1, subchannel index: ObOOOlO (decimal values) 

Input Data (Hex) 

45 29 C4 79 AD OF 55 28 AD 87 B5 76 1 A 9C 80 50 45 IB 9F D9 2A 88 95 EB AE B5 
Randomized Data (Hex) 

D4 BA Al 12 F2 74 96 30 27 D4 88 9C 96 E3 A9 52 B3 15 AB FD 92 53 07 32 CO 62 00 

Convolutionally Encoded Data (Hex) 

EE C6 Al CB 7E 04 73 6C BC 61 95 D3 B7 C4 EF 0E 4C 76 CF DC 70 69 B3 CE DB E0 E5 B7 B5 
4E 88 7D A4 AE31 30 

Interleaved Data (Hex) 

B4 FF DA 06 E5 42 EC IF 86 7C 29 93 9C AD 83 42 6B FE FC 6D CB F6 53 85 AE 68 22 7A CE 
Bl E7 52B0ECBA95 

Subcarrier Mapping (frequency offset index: I value Q value) - 
1st data symbol: 

-100: -1 -3, -99: 3 1, -98: -3 -3, -97: -3 -3, -96: -3 3, -95: -1 -1, -38: pilot = 1 0, -37: 1 1, -36: 3 - 
1, -35: -3 -1, -34: 3 3, -33: 3 1, -32: 1 -1, 1: -3 -1, 2: -3 1, 3: 1 3, 4: -3 -3, 5: -1 1, 6: 3 -1, 64: 3 - 
3, 65: -3 1, 66: 1 -1, 67: -1 3, 68: -1 3, 69: 1 -3 
2nd data symbol: 

-100: -1 3, -99: -3 1, -98: -1 -1, -97: -3 3, -96: -1 1, -95: 1 -3, -38: pilot = -1 0, -37: 3 1, -36: 1 - 
1, -35: 3 -1, -34: -1 -3, -33: -3 -3, -32: -3 -1, 1: -3 -3, 2: -3 1, 3: 3-1,4: -3 3, 5: -3 1, 6: -1 -3, 64: 
-3 -3, 65: 3 -1, 66: 3 3, 67: 1 -3, 68: -1 1, 69: 3 3 
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3rd data symbol: 

-100: -1 -1, -99: -3 -1, -98: 3 -1, -97: -1 1, -96: 1 -1, -95: 1 -1, -38: pilot = 1 0, -37: 3 -3, -36: -1 
-1, -35: -3 1, -34: -3 -1,-33: -1 -3, -32:1 3, 1: -3 -1, 2: 3 -3, 3: 3 3, 4: 1 -1, 5: -1 -3, 6: 1 1, 64: -3 
-1, 65: -3 1, 66: -1 -3,' 67: -1 -1, 68: -1 3, 69: 3 3 

Note that the above 16-QAM values (all values with exception of the BPSK pilots) are to be normalized with 
a factor 1 / VlO as indicated in Figure 203. 

8.3.3.5.3 Subchannelization (1 subchannel) 

Modulation Mode: QPSK, rate 3/4, Symbol Numbers within burst: 1-5, UIUC: 7, BSID: 1, Frame Number: 
1, subchannel index: ObOOOOl (decimal values) 

Input Data (Hex) 

45 29 C4 79 AD OF 55 28 AD 87 
Randomized Data (Hex) 

D4 BA Al 12 F2 74 96 30 27 D4 00 00 
Convolutionally Encoded Data (Hex) 

EE C6 Al CB 7E 04 73 6C BC 61 95 D3 B7 DF 00 
Interleaved Data (Hex) 

BC EC Al F4 8A 3A 7A 4F 78 39 53 87 DF 2A A2 
Subcarrier Mapping (frequency offset index: I value Q value) 

1st data symbol: 

-100: -1 1, -99: -1 -1, -98: -1 -1, -37: 1 1, -36: -1 -1, -35: -1 1, 1: -1 -1, 2: 1 1, 3: -1 1, 64: -1 1, 
65: 1 1,66: 1 -1 
2nd data symbol: 

-100: -1 -1, -99: -1 -1, -98: 1 -1, -37: 1 1, -36: -1 1, -35: 1 1, 1: -1 1, 2: -1 1, 3: 1 1, 64: -1 -1, 65: 
-1 1, 66: -1 1 
3rd data symbol: 

-100: 1 -1, -99: -1 -1, -98: -1 1, -37: -1 1, -36: 1 -1, -35: 1 1, 1: -1 -1, 2: -1 -1, 3: 1 -1, 64: -1 -1, 
65: -1 1,66: 1 1 
4th data symbol: 

-100: 1 1, -99: -1 -1, -98: -1 1, -37: 1 -1, -36: 1 -1, -35: 1 -1, 1: 1 1, 2: -1 -1, 3: -1 1, 64: 1 1, 65: 
1-1, 66: -1-1 
5th data symbol: 

-100: -1 -1, -99: 1 -1, -98: -1 -1, -37: -1 -1, -36: 1 1, -35: -1 1, 1: -1 1, 2: -1 1, 3: -1 1, 64: -1 1, 
65:1 1,66:4 1 

Note that the above QPSK values are to be normalized with a factor 1 /Jl as indicated in Figure 203. 
8.3.3.6 Preamble structure and modulation 

All preambles are structured as either one of two OFDM symbols. The OFDM symbols are defined by the 
values of the composing subcarriers. Each of those OFDM symbols contains a cyclic prefix, which length is 
the same as the CP for data OFDM symbols. 



446 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



The first preamble in the downlink PHY PDU, as well as the initial ranging preamble, consists of two 
consecutive OFDM symbols. The first OFDM symbol uses only subcarriers the indices of which are a 
multiple of 4. As a result, the time domain waveform of the first symbol consists of four repetitions of 64- 
sample fragment, preceded by a CP. The second OFDM symbol utilizes only even subcarriers, resulting in 
time domain structure composed of two repetitions of a 128-sample fragment, preceded by a CP. The time 
domain structure is exemplified in Figure 205. This combination of the two OFDM symbols is referred to as 
the long preamble. 
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Figure 205— Downlink and network entry preamble structure 

The frequency domain sequences for all full-bandwidth preambles are derived from the sequence: 

Pall(-100:100) = { -1-j, 1+j, 1-j, 1-j, -1+j, H 1-j, 1-j, 1+j, 1+j, 1+j, -1-j, 1+j, -1-j, -1-j, - 

1+j, 1-j, 1-j, 1+j, 1-j, 1-j, -1+j, 1-j, 1-j, 1-j, 1+j, -1-j, 1+j, 1+j, -1-j, 1+j, -1-j, -1-j, 1-j,- 

i+j, H H -i-j, i+j, i-j, i-j, -i+j, i-j, i-j, i-j, i+j, -i-j, i+j, i+j, -i-j, i+j, -l-j, -l-j, l-j, - 
l+j, i+j, i+j, i-j, -i+j, i+j, i+j, -i-j, i+j, i+j, i+j, -i+j, i-j, -i+j, -i+j, i-j, -i+j, i-j, i-j, 
i+j, -i-j, -i-j, -i-j, -i+j, i-j, -i-j, -i-j, i+j, -i-j, -i-j, -i-j, i-j, -i+j, i-j, i-j, -i+j, i-j, -i+j, 

-1+j, -l-j, 1+j, 0, -l-j, 1+j, -1+j, -1+j, -l-j, 1+j, 1+j, 1+j, -l-j, 1+j, l-j, l-j, l-j, -1+j, -1+j, - 

1+j, -1+j, 1-j, -1-j, -1-j, -1+j, 1-j, 1+j, 1+j, -1+j, 1-j, 1-j, 1-j, -1+j, 1-j, -1-j, -1-j, -1-j, 1+j, 
1+j, 1+j, 1+j, -1-j, -1+j, -1+j, 1+j, -1-j, 1-j, 1-j, 1+j, -1-j, -1-j, -1-j, 1+j, -1-j, -1+j, -1+j, - 
1+j, 1-j, 1-j, 1-j, 1-j, -1+j, 1+j, 1+j, -1-j, 1+j, -1+j, -1+j, -1-j, 1+j, 1+j, 1+j, -1-j, 1+j, 1-j, 1- 
j, 1-j, -1+j, -1+j, -1+j, -1+j, 1-j, -1-j, -1-j, 1-j, -1+j, -1-j, -1-j, 1-j, -1+j, -1+j, -1+j, 1-j, -1+j, 

1+j, 1+j, 1+j, -1-j, -1-j, -1-j, -1-j, 1+j, 1-j, 1-j} (77) 
The frequency domain sequence for the 4 times 64 sequence is defined by: 



^4jc64(jk) - | 



Jl j2 conj(P ALL (k)) 

0 



KodA = o 

KodA** 



(78) 



In Equation (78), the factor of equates the Root-Mean-Square (RMS) power with that of the data section. 
The additional factor of Jl is related to the 3 dB boost. 

The frequency domain sequence for the 2 times 128 sequence /'even x% defined by: 



EVEN(k) 



-{ 



0 



(79) 



In Peven, the factor of Jl is related to the 3 dB boost. 



In the uplink, when the entire 16 subchannels are used, the data preamble, as shown in Figure 206 consists of 
one OFDM symbol utilizing only even subcarriers. The time domain waveform consists of 2 times 128 
samples preceded by a CR The subcarrier values shall be set according to the sequence /'even- ™ s 
preamble is referred to as the short preamble. This preamble shall also precede all allocations during the 
AAS portion of a frame and shall be used as burst preamble on the downlink bursts when indicated in the 

dl-mapje: 
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CP 



128 



128 



Figure 206— P E ven time domain structure 



In the downlink bursts, which start with a preamble and which fall within the STC-encoded region, the 
preamble shall be transmitted from both transmit antennas simultaneously and shall consist of a single 
OFDM symbol. The preamble transmitted from the first antenna shall use only even subcarriers, the values 
of which are set according to the sequence P E VEN- ^ preamble transmitted from the second antenna shall 
use only odd subcarriers, the values of which shall be set according to the sequence P 0 DD- 



ODD(k) 



(80) 



The AAS preamble shall be composed of two identical OFDM symbols. Each symbol shall be transmitted 
from up to four beams. The same beams shall be used in the first and second symbols. This preamble shall 
be used to mark AAS DL zone slots and to perform channel estimation. If the BS supports more than four 
antennas, the subset that is transmitted on a single AAS preamble may be varied from frame to frame. The 
preamble from beam m, m = 0...3, shall be transmitted on subcarriers m mod 4 and shall use the sequence 



p aas S iven bv me following equations. 



For m = 0 



<*) = 



conj.{P ALL (k)} 



k mod 4 * 0 
k mod 4 = 0 



(81) 



Form = 1.. .3 



(k) 



■I 



0 

conj{P ALL (k + 2-m)} 



k mod 4 * m 
k mod 4 = m 



(82) 



Using mesh, bursts sent in the control subframe shall start with the long preamble. In the data subframe, the 
bursts shall by default start with the long preamble, but neighbors may negotiate to use the short preamble 
by setting the preamble flag in the Neighbor Link Info field. 

In mesh mode, bursts sent in the control subframe shall start with the long preamble. In the mesh data sub- 
frame, the bursts shall be default start with the long preamble, but neighbors may negotiate to use the short 
preamble by setting the preamble flag in the Neighbor Link Info field. 

In the uplink, when subchannelization transmissions are employed, the data preamble consists of a 256 
sample sequence preceded by a CP whose length is the same as the cyclic prefix for data OFDM symbols. 
This preamble is referred to as the subchannelization preamble. The frequency domain sequence for the 256 
samples is defined by P SUB . Preamble subcarriers that do not fall within the allocated subchannels shall be 
set to zero. 



^sub(- 10 0:100) = { i+j, i+j, -l-j, i+j, -i+j, i+j, i+j, i+j, -H -l-j, i-j, -i-j, H i+j, i-j, i+j> i+j> -1-j* -H 

' i+jri+jri+iri+i."-i-j."i+j. -y+h i+j. i+j. . 



j , j , j, J, j , «»' j' *" j 

i+j, l-j, i+j, -l-j, l+j, l+j, i+j, i+j, -l-j, i+j, -i+j, i+j, i+j. i+j. -i-j. -i-j. 1-j- -H -}-'h 

1+j, 1-j, 1+j, 1+j, -1-j, -1-j, 1+j, 1-j, 1+j, -1-j, lH" 1 



1+j.- 
1+j.- 
-1+j,- 



, -1-j, -1-j, 1-j, -1-j, 1-j, -1-j, -1+j, "1-j, "1-j, 1+j, 1+J, "1-J. "1+J. "1-J. 1+J. -1-J- "I-J- 1+J- 

, -1-j, 1+j, -1+j, 1+j, 1+j, 1+j, -1-j, -1-j, 1-j, -1-j, 1-j, -1-j. -1+J. -1-J. ;H 1+J. 1+J? -H 
j, -1-j, 1+j, -1-j, -l-j, 0,1+j, 1+j, -1-j, 1+j, -1+j, 1+j, 1+j, 1+j, -1-j, -l-J. 1-J. -1-J. 1-J. 1+J. 
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H, l+j, l+j, -H -l-j, i+j, H l+j, -H, l+j, l+j, -H -H i+j, -l-j, l-j, -l-j, -l-j, -i-j, 
l+j, i+j, -i+j, i+j, i-j, -i-j, -i+j, -l-j, -l-j, i+j, i+j, -i-j, -i+j, -i-j, i+j, -i-j, -i-j, -i-j, -i- 
j, l+j, -i-j, i-j, -i-j, -i-j, -i-j, l+j, i+j, -i+j, i+j, -i+j, i+j, i-j, i+j, i+j, -i-j, -i-j, i+j, i-j, 
i+j, -i-j, i+j, i+j, i+j, i+j, -i-j, l+j, -l+j, l+j, l+j, i+j, -i-j, -i-j, i-j, -i-j, -i-j, -i-j, -i+j, 

-l-j, -l-j, l+j,.l+j, -l-j, -l+j, -l-j, l+j, -l-j, -l-j} (83) 

In the case that the uplink allocation contains midambles, the midambles will consist of one OFDM symbol 
and shall be identical to the preamble used with the allocation. 

UL preambles and midambles may be cyclically delayed by an integer number of samples. This is indicated 
by the UL-Physical modifier IE (8.3.6.3.7). 

8.3.4 Transmission convergence (TC) sublayer 

The transmission convergence sublayer, as described in 8.1.4.3, is an optional mechanism for the OFDM 
PHY and can be enabled on a per-burst basis for both uplink and downlink through the DIUC/UIUC 
definitions in the DCD/UCD messages, respectively. The TCSJENABLE parameter is coded as a TLV tuple 
as defined in 11.4.2 (i.e., DCD burst profile encodings) and 11.3.1.1 (i.e., UCD burst profile encodings). 

At SS initialization, the TC sublayer capability is negotiated between the BS and SS through SBC-REC/ 
SBC-RSP messages as an OFDM PHY specific parameter. The TC sublayer capability parameter is coded as 
a TLV tuple as defined in 11.8.3.6.5. 

8.3.5 Frame structure 
8.3.5.1 PMP 

In licensed bands, the duplexing method shall be either FDD or TDD. FDD SSs may be H-FDD. In license- 
exempt bands, the duplexing method shall be TDD. 

The frame interval contains transmissions (PHY PDUs) of BS and SSs, gaps and guard intervals. 

The OFDM PHY supports a frame-based transmission. A frame consists of a downlink subframe and an 
uplink subframe. A downlink subframe consists of only one downlink PHY PDU. A uplink subframe 
consists of contention intervals scheduled for initial ranging and bandwidth request purposes and one or 
multiple uplink PHY PDUs, each transmitted from a different SS. 

A downlink PHY PDU starts with a long preamble, which is used for PHY synchronization. The preamble is 
followed by a FCH burst. The FCH burst is one OFDM symbol long and is transmitted using BPSK rate 1/2 
with the mandatory coding scheme. The FCH contains DL_Frame_Prefix to specify burst profile and length 
of one or several downlink bursts immediately following the FCH. A DL-MAP message, if transmitted in 
the current frame, shall be the first MAC PDU in the burst following the FCH. An UL-MAP message shall 
immediately follow either the DL-MAP message (if one is transmitted) or the DLFP. If UCD and DCD 
messages are transmitted in the frame, they shall immediately follow the DL-MAP and UL-MAP messages. 
Although burst #1 contains broadcast MAC control messages, it is not necessary to use the most robust well- 
known modulation/coding. A more efficient modulation/coding may be used if it is supported and applicable 
to all the SSs of a BS. 

The FCH is followed by one or multiple downlink bursts, each transmitted with different burst profile. Each 
downlink burst consists of an integer number of OFDM symbols. Location and profile of the first downlink 
burst is specified in the Downlink Frame Prefix (DLFP). The location and profile of the maximum possible 
number of subsequent bursts shall also be specified in the DLFP. At least one full DL-MAP must be broad- 
cast in burst #1 within the Lost DL-MAP Interval specified in Table 342. Location and profile of other bursts 
are specified in DL-MAP. Profile is specified either by a 4-bit RateJD (for the first DL burst) or by DIUC. 
The DIUC encoding is defined in the DCD messages. HCS field occupies the last byte of DLFP. If there are 
unused IEs in DLFP, the first unused IE must have all fields encoded as zeros. 
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The DL Subframe may optionally contain an STC zone in which all DL bursts are STC encoded. If an STC 
zone is present, the last used IE in the DLFP shall have DIUC = 0 (see Table 237) and the IE shall contain 
information on the start time of the STC zone (see Table 241). The STC zone ends at the end of the frame. 

The STC zone starts from a preamble and an STC encoded FCH-STC burst, which is one symbol with the 
same payload format as specified in Table 241. The FCH-STC burst is transmitted at BPSK rate Vi. It is 
followed by one or several STC encoded PHY bursts. The first burst in the STC zone may contain a DL- 
MAP applicable only to the STC zone. If DL-MAP is present, it shall be the first MAC PDU in the payload 
of the burst. 



With the OFDM PHY, a PHY burst, either a downlink PHY burst or an uplink PHY burst, consists of an integer 
number of OFDM symbols, carrying MAC messages, i.e., MAC PDUs. To form an integer number of OFDM 
symbols, unused bytes in the burst payload may be padded by the bytes OxFE Then the payload should be 
randomized, encoded, and modulated using the burst PHY parameters specified by this standard. If an SS does 
not have any data to be transmitted in an UL allocation, the SS shall transmit an UL PHY burst containing a 
bandwidth request header as defined in Figure 20, with BR = 0 and its basic CID. If the allocation is large 
enough, an AAS enabled SS may also provide an AAS Feedback Response (AAS-FBCK-RSP) message 
(6.3.2.3.40). An SS shall transmit during the entirety of all of its UL allocations, using the standard padding 
mechanism (6.3.3.7) to fill allocations if necessary. 

In each TDD frame (see Figure 207), the TTG and RTG shall be inserted between the downlink and uplink 
subframe and at the end of each frame, respectively, to allow the BS to turn around. 
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Figure 207— Example of OFDM frame structure with TDD 
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In TDD and H-FDD systems, subscriber station allowances must be made by a transmit-receive turnaround 
gap SSTTG and by a receive-transmit turnaround gap SSRTG. The BS shall not transmit downlink 
information to a station later than (SSRTG+RTD) before its scheduled uplink allocation, and shall not 
transmit downlink information to it earlier than (SSTTG-RTD) after the end of scheduled uplink allocation, 
where RTD denotes Round-Trip Delay. The parameters SSRTG and SSTTG are capabilities provided by the 
SS to BS upon request during network entry (see 11.8.3.1). 
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Figure 208— Example of OFDM frame structure with FDD 
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Table 225— OFDM downlink frame prefix format 



Syntax 


Size 


Notes 


DL_Frame_Prefix_FormatO { 






Base_Station_ID 


4 bits 


4 LSB of BS ID. The burst 
specified by the DLFP shall not 
be decoded if these bits do not 
match those of the BS on which it 
is registered. 


Frame_Number 


4 DltS 


4 L,bt> or tne frame iMumoer 
DCD Channel Encoding as j 
specified in Table 358. 


Configuration_Change_Count 


4 bits 


4 LSB of Change Count value as 
specified in 6.3.2.3.1. 


reserved 


4 bits 


Shall be set to zero 


LOT {Jl—Uf U v. U~r-r) [ 






DL_Frame_Prefix JE() { 






RateJD/DIUC 


4 bits 


For the first information element 
it shall be Rate_ID encoded 
according to the Table 224. For 
following IEs this field is DIUC 
that defines the burst profile of 
the corresponding burst. 


if(DIUC != 0){ 






Preamble present 


1 bits 


If "1," preamble is placed before 
the burst. 


Length 


1 1 bits 


Number or UrUJvl symbols in tne 
burst. 


} else { 






Start Time 


12 bits 


Start time of STC zone in units of 
symbol duration counted from the 
beginning of the frame. 


} 






} . 






} 






HCS 


8 bits 


An 8-bit Header Check Sequence; 
calculated as specified in Table 5. 


} 







HCS 

An 8-bit Header Check Sequence used to detect errors in the DL Frame Prefix. The generator poly- 
nomial is g(D)= £> 8 + D 2 + D + 1. The transmitter shall take all the bytes in the DL Frame Prefix 
except the byte reserved for the HCS and divide them by g(x) and use the remainder as HCS code. 
At the receiver, dividing the DL_Frame_Prefix by g(x) then gives the remainder 0 if correct. 
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(Example: BS_ID=0x03 19B8 1 2A9B8 (4LSB=0x8), Frame_Number=l 87662 (4LSB=0xE), 
Configuration_Change_Count=159 (4LSB=0xF), Reserved=0xF, Rate_ID=l (0x1), Length=204 
(OxOCC), DLFPJE(l) DIUC=1 (0x1), DLFPJE(l) Midamble Present = 1 / Burst_Length=50 
(0x832), all following DLFP_IEs=0 (8 times 0x0000). Encode byte sequence 
[0x8EFFl OCC 1 83200000000] and obtain 0x99 as the HCS byte.) 

8.3.5.2 PMP-AAS Zone 

DL transmission to an SS or group of SSs consists of two fractions. The first fraction of the transmission 
consists of one or several repetitions of a short preamble followed by FCH symbol (Figure 3). The second 
fraction is called Body. 

FCH payload is called "AAS DL Frame Prefix" (AASJDLFP). FCH shall be transmitted at the lowest possi- 
ble modulation. Each pair preamble-FCH may be transmitted either at narrow beam or at wide beam. 
Optionally, the same preamble-FCH pair may be repeated at several beams thus implementing space 
diversity. In the case when FCH is repeated for diversity, all copies have the same content and therefore soft 
combining might be employed at the SS receiver. 

AAS_DLFP contains information (DL IEs or UL IEs) on location and transmission rate of PHY bursts. 
There is a possibility of more than one concatenated DL PHY bursts, each one described by a DL IE. UL IEs 
specify either UL PHY burst (a single burst per SS) or contention region for initial ranging or bandwidth 
requesting. 

Body may be transmitted at a directed beam and may start either immediately after FCH or at some distance. 
In the latter case, it shall start from a preamble. The payload of the burst may contain private DL-MAP 
and/or UL-MAP messages. 

Alternatively, AASJDLFP may contain UL IEs. There are two options: 

1) A single UL IE. 

2) "Compressed" UL IE, which contains a network entry allocation and a regular allocation. 
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An example of AAS Zone layout is shown at Figure 209. 
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Figure 209— Structure of AAS Zone 

The structure of AAS_DLFP is specified in Table 226. 

Table 226— AAS_DLFP Structure 



Syntax 


Size 


Notes 


AAS_DLFP(){ 






Base_Station_ID 


4 bits 


4LSBofBSID. 


Frame_Number 


4 bits 


4 LSB of the Frame Number 
DCD Channel Encoding as 
specified in Table 312. 


reserved 


6 bits 


Shall be set to zero. 


Dir 


lbit 


Allocation direction: Dir = * V 
means UL. 


Allocation Start 


13 bits 


Points to the start of Body 
fraction; expressed in the terms of 
offset from the beginning of the 
AAS preamble. 


if (Dir ==T){ 






UCD_Configuration_Change_Count 


3 bits 


3 LSB of UCD Change Count 
value as specified in 6.3.2.3.3. 
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Table 226— AAS_DLFP Structure (continued) 



I Syntax 


Size 


Notes 


Comp_UL 


1 bit 


Compressed UL IE is present if 
bit is set to l,else full UL IE. 


If (CompJJL == T){ 






AAS_COMPJJL_IE() 


48 bits 




} else { 






AAS_DLFP_UL_IE() 


48 bits 




} 






} else { 






reserved 


1 bit 


Shall be set to zero 


DCD_Configuration_Change_Count 


3 bits 


3 LSB of DCD Change Count 
value as specified in 6.3.2.3.1. 


AAS_DLFP_DLJE0 


16 bits 




AAS_DLFP_DLJE() 


16 bits 




AAS_DLFP_DL_IE() 


16 bits 




} 






HCS 


8 bits 


An 8-bit Header Check Sequence; 
calculated as specified in Table 5. 


} 






Table 227— AAS_DLFP_DL IE format 


Syntax 


Size 


Notes 


AAS_DLFP_DL_IE() { 






Rate_D) /DIUC 


4 bits 


For the first information element 
it shall be Rate_ID encoded 
according to the Table 224. For 
following IEs this field is DIUC 
that defines the burst profile of 
the corresponding burst. 


Preamble present 


1 bit 


If 4 1\ midamble is placed before 
the burst. 


Length 


11 bits 


Number of OFDM symbols in the 
burst. 


} 
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Table 228— AAS_DLFP_UL IE format 



Syntax 


Size 


Notes 


AASJDLFP_UL_IE() { 






UIUC 


4 bits 


UIUC value; see Table 230. 


If(UIUC == 1){ 






AAS_NW_Entry_Response_IE() 


16 bits 




}elseIf(UIUC==3){ 






Focused_Contention_Response_IE() 


16 bits 




} else { 






CID 


16 bits 


If UIUC = 2, must be multicast or 
broadcast CID, the allocation will 
be used for multicast polling. 


} 






Preamble time shift 


8 bits 


Shift to be performed on pream- 
ble and midambles. bee o.J.o.3./. 


| reserved 


1 bits 


Shall be set to zero. 


Subchanneljndex 






Midamble repetition interval 


2 bits 


ObOO: Preamble only 

ObOl: Midamble after every 8 

data symbols 
Ob 10: Midamble after every 16 t 

data symbols 
Obll: Midamble after every 32 

data symbols 


Duration 


9 bits 


In OFDM symbols. 


} 







AAS_COMP_UL_IE shall be used to specify two UL allocations; one of them must be for NW entry; 
another one is either unicast allocation or multicast/broadcast polling allocation. 



Table 229— AAS_COMP_UL IE format 



Syntax 


Size 


Notes 


AAS_COMP_UL_IE0 { 






UIUC 


4 bits 


UIUC value; see Table 230. 


If(UIUC==l){ 






\ AAS_NW_Entry_Response_IE() 


16 bits 




Jelse If (UIUC == 3) { 






Focused_Contention_Response_IEO 


16 bits 
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Table 229— AAS_COMP_UL IE format (continued) 



Syntax 


Size 


Notes 


} else { 






CID 


16 bits 


For regular allocation. 








Subchannel Tnrfpx NW Fntrv 




Fnr NW pntrv ullnr'iit'inn 

rui i^i yy entry aiiuLauuii. 


Du ration_NW_entry 


9 bits 


Duration of NW entry allocation 
in OFDM symbols. 


SubchanneLIndex 


5 bits 


For regular allocation. 


Duration 


12 bits 


Duration of regular allocation in 
OFDM symbols. 


} 







Table 230— UIUC Usage in AAS Zone 



UIUC 


Usage 


0 


reserved 


1 


AAS NW Entry Response 


2 


REQ Region Full 


3 


REQ Region Focused 


4 


Focused Contention 
response IE 


5-13 


Burst Profiles 
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Table 231— AAS NW Entry Response IE format 



Syntax 


Size 


Notes 


AAS_NW_Entry_Response_IE(){ 






Frame Number Index 


4 bits 


4 LSB of Frame Number field. 


Network Entry Code 


4 bits 


Random code sent by the SS in 
AAS Network Entry Request. 


reserved 


8 bits 


Shall be set to zero. 


} 







Frame Number Index 

Identifies the frame in which the network entry request, which this message responds to, was 
transmitted. The four least significant bits of the frame number are used as the frame number index. 
Network Entry Code 

Random code sent by the SS in AAS Network Entry Request. 
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8.3.5.3 Mesh 



In addition to the PMP frame structure in 8.3.5.1, an optional frame structure (see Figure 210) is defined to 
facilitate Mesh networks. 
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Figure 210 — Mesh frame structure 



A Mesh frame consists of a control and data subframe. The control subframe serves two basic functions. 
One is the creation and maintenance of cohesion between the different systems, termed "network control" in 
Figure 210. The other is the coordinated scheduling of data-transfers between systems, termed "schedule 
control" in Figure 210. Frames with a network control subframe occur periodically, as indicated in the 
Network Descriptor. All other frames have a schedule control subframe. The length of the control subframe 
is fixed and of length MSH-CTRL-LEN x 7 OFDM symbols, with MSH-CTRL-LEN indicated in the Network 
Descriptor. 

During a network control subframe, the first seven symbols are allocated for network entry, followed by 
MSH-CTRL-LEN - 1 sets of seven symbols for network configuration. During a schedule control subframe, 
the Network Descriptor indicates how many (MSH-DSCH-NUM) Distributed Scheduling messages may 
occur in the control subframe. The first (MSH-CTRL-LEN -MSH-DSCH-NUM) x 7 symbols are allocated to 
transmission bursts containing MSH-CSCH and MSH-CSCF PDUs, whereas the remainder is allocated to 
transmission bursts containing MSH-DSCH PDUs. 

Distributed Scheduling messages (using the long preamble) may further occur in the data subframe if not in 
conflict with the scheduling dictated in the control subframe. 
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All transmissions in the control subframe are sent using QPSK-1/2 with the mandatory coding scheme. The 
data subframe is divided into minislots, which are, with possible exception of the last minislot in the frame, 
of size ceiling [(OFDM symbols per frame - MSH-CTRL-LEN x 7 )/256]. A scheduled allocation consists of 
one or more minislots. 

8.3.5.4 Frame duration codes 

Table 232 indicates the specific frame durations that are allowed. The frame duration used can be 
determined by the periodicity of the frame start preambles. Once a specific frame duration has been selected 
by the BS, it should not be changed. Changing the frame duration shall force all SSs to resynchronize to the 
BS. 



Table 232 — OFDM frame duration (7 F ms) codes 



Code 


Frame duration (ms) 


Frames per second j 


0 


2.5 


400 


1 


4 


250 


2 


5 


200 


3 


8 


125 1 


4 


10 


100 


5 


12.5 


80 


6 


20 


50 


7-255 


reserved 


reserved 



8.3.5.5 Burst Profile format 

Table 233 defines the format of the Downlink_Burst_Profile, which is used in the DCD message (6.3.2.3.1). 
The Dowjilink_Burstj>rofile is encoded with a Type of 1, an 8-bit length, and a 4-bit DIUC. The DIUC field 
is associated with the Downlink Burst Profile and Thresholds. The DIUC value is used in the DL-MAP 
message and in DLFP to specify the Burst Profile to be used for a specific downlink burst. 



Table 233— OFDM Downlink_Burst_Profile format 



Syntax 


Size 


Notes 


Downlink_Burst_Profile { 






Type=l 


8 bits 




Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


DIUC 


4 bits 




TLV encoded information 


variable 




} 
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Table 234 defines the format of the Uplink_Burst_ProfiIe, which is used in the UCD message (63.2.3.3). 
The Uplink_Burst_Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit UIUC. The UIUC field is 
associated with the Uplink Burst Profile and Thresholds. The UIUC value is used in the UL-MAP message 
to specify the Burst Profile to be used for a specific uplink burst. 



Table 234— OFDM Uplink_Burst_Profile format 



Syntax 


Size 


Notes 


Uplink_Burst_Profile { 






Type=l 


8 bits 




Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


UIUC 


4 bits 




TLV encoded information 


variable 




} 







8.3.6 Map message fields and lEs 

8.3.6.1 DL-MAP PHY synchronization field 

The PHY synchronization field of the DL-MAP message is structured as follows. 



Table 235— OFDM PHY synchronization field 



Syntax 


Size 


Notes 


Synchronizationjield { 




The OFDM PHY synchronization field 
is empty (zero bytes long). 


} 







8.3.6.2 DL-MAP IE format 

DL-MAP IEs have the format listed in Table 236: 



Table 236— OFDM DL-MAP IE 



Syntax 


Size 


Notes 


DL-MAP_IE() { 






CID 


16 bits 




DIUC 


4 bits 





Copyright ©2004 IEEE. All rights reserved. 



461 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 1 6: 



Table 236— OFDM DL-MAP IE (continued) 



Syntax 


Size 


Notes 


r ICalllUlC picsciu 


1 bit 


0 = not present, 1 = present 

if (DIUC==15 and not Extended 

DIUC = 3), shall be 0. 


Start Time 


11 bits 




if (DIUC ==15) 






Extended DIUC dependent IE 


variable 


See subclauses following 8.3.6.2.2. 


Padding nibble, if needed 


4 bits 


Completing to nearest byte. 


} 







Connection Identifier (CID) 

Represents the assignment of the IE to a broadcast, multicast or unicast address. 
If the broadcast or multicast CID is used then it is possible to concatenate unicast MAC PDUs (with 
different CIDs) into a single DL burst. During a broadcast or multicast DL burst it is the 
responsibility of the BS to ensure that any MAC PDUs sent to an HFDD SS do not overlap (in time; 
taking TTG and RTG into account) any UL allocations for that SS. An HFDD SS for which a DL 
MAP IE and UL MAP IE overlap in time shall use the UL allocation and discard DL traffic during 
the overlapping period. 
DIUC 

A 4-bit DIUC shall be used to define the burst type associated with that time interval. Burst 
Descriptor shall be included into DCD message for each DIUC used in the DL-MAP except those 
associated with Gap, End of Map and Extended. The DIUC shall be one of the values defined in 
Table 237. 
Preamble present 

If set, the indicated burst shall start with the short preamble. 
Start Time 

Indicates the start time, in units of symbol duration, relative to the start of the first symbol of the 
PHY PDU (including preamble) where the DL-MAP message is transmitted. The end of the last 
allocated burst is indicated by allocating a an End of Map burst (DIUC = 14) with zero duration. 
The time instants indicated by the Start Time values are the transmission times of the first symbol 
of the burst including preamble (if present). 
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8.3.6.2.1 DIUC allocations 

Table 237 contains the DIUC values used in DL-MAP_IE(). 

Table 237— OFDM DIUC values 



DIUC 


Usage 


0 


STC zone 


1-11 


Burst Profiles 


12 


reserved 


13 


Gap 


14 


End of Map 


15 


Extended DIUC 



8.3.6.2.2 DL-MAP extended IE format 

A DL-MAP IE entry with a DIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 238. A station shall ignore an extended IE entry with an extended DIUC 
value for which the station has no knowledge. In the case of a known extended DIUC value but with a length 
field longer than expected, the station shall process information up to the known length and ignore the 
remainder of the IE. 



Table 238— DL-MAP extended IE format 



Syntax 


Size 


Notes 


DL.Extended JE() { 






Extended DIUC 


4 bits 


0x00..0x0F 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







8.3.6.2.3 Channel measurement IE format 

An extended IE with an extended DIUC value of 0x00 is issued by the BS to request a channel measurement 
report (see 6.3.2.3.33). The Channel_Measurement_IE() shall be followed by the End of map IE (DIUC = 14). 
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Table 239— OFDM Channel measurement IE format 



Syntax 


Size 


Notes 


Channel JVIeasurement_IE() { 






Extended DIUC 


4 bits 


CHM = 0x00 


Length 


4 bits 


Length = 0x01 


Channel Nr 


8 bits 


Channel number (see 8.5.1) 
Set to 0x00 for licensed bands 


} 







8.3.6.2.4 DL-WIAP AAS IE format 

Within a frame, the switch from non-AAS to AAS-enabled traffic is marked by using the DIUC = 15 with 
the AASJEQ to indicate that the subsequent allocations, until the start of the first UL-MAP allocation 
using TDD, and until the end of the frame using FDD, shall be for AAS traffic. When used, the CID in the 
DL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short 
preamble. 



Table 240— OFDM AAS DL IE format 



Syntax 


Size 


Notes 


AAS_DL_IE() { 






Extended DIUC 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x00 


} 







8.3.6.2.5 DL-MAP STC IE format 

In the DL-MAP, an STC enabled BS (see 8.3.8) may transmit DIUC=15 with the STC_IE() to indicate that 
the subsequent allocations shall be STC encoded. No preceding downlink allocations shall be STC encoded 
and all subsequent downlink allocations until the end of the frame shall be STC encoded. After this 
allocation, the BS shall transmit from both its antennas until the end of the frame. The first downlink 
allocation following the STC JE. shall contain a preamble. The number of OFDM data symbols between two 
preambles and the number of OFDM data symbols between the last preamble and the end of the downlink 
subframe must be even. 
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Table 241 — OFDM STC IE format 



Syntax 


Size 


Notes 


STCJEO { 






Extended DIUC 


4 bits 


STC = 0x04 ! 


Length 


4 bits 


Length = 0x00 


} 







8.3.6.2.6 DL-MAP concurrent transmission IE format 

In the DL-MAP, a BS may transmit UIUC=15 with the DL_Concurrent_IE() to specify one of a set of 
parallel downlink bursts for transmission. This format explicitly specifies the duration of the corresponding 
downlink burst. A preamble may precede the downlink burst specified by this IE. 



Table 242— OFDM DL-MAP Concurrent transmission IE format 



Syntax 


Size 


Notes 


DL_Concurrent_IE() { 






Extended DIUC 


4 bits 


CONC = 0x03 


Length 


4 bits 


Length = 2 


DIUC 


' 4 bits 




Duration 


12 bits 


Duration of burst in OFDM symbols 


} 







DIUC: 

A 4-bit DIUC shall be used to define the burst type associated with that time interval. Burst 
Descriptor shall be included into DCD message for each DIUC used in the DL-MAR The DIUC 
shall be one of the Burst Profile values (1-12) defined in Table 237. 
Duration: 

Indicates the duration of the burst, in units of OFDM symbols. The duration is inclusive of the 
preamble contained in the allocation, if present. 

8.3.6.2.7 DL-MAP Physical Modifier IE format 

The Physical Modifier Information Element indicates that the subsequent bursts utilize a preamble, if 
present, which is cyclically delayed in time by M samples. Equation (84) defines the waveform transmitted 
during these training symbols. The PHYMOD_DL_IE can appear anywhere in the DL map, and it shall 
remain in effect until another PHYMOD_DL_EE is encountered, or until the end of the DL map. 

Only stations that are allocated in bursts specified by a DL-MAP concurrent transmission IE format 
(8.3.6.2.6) shall receive the timely shifted preamble. 



Copyright ©2004 IEEE. All rights reserved. 



465 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



Table 243— OFDM DL-MAP Physical Modifier IE format 



Syntax 


Size 


Notes 


PHYMOD_DL_IE() { 






Extended DIUC 


4 bits 


PHYMOD = 0x01 


Length 


4 bits 


Length = 1 


Preamble Time Shift 


8 bits 




} 







Preamble Time Shift 

The parameter indicating how many samples of cyclic shift are introduced into the training symbols 
of the following bursts [M in Equation (84)]. 

8.3.6.2.8 DL-MAP dummy IE format 

An SS shall be able to decode the DL-MAP Dummy IE. A BS shall not transmit this IE (unless under test). 
An SS may skip decoding downlink bursts scheduled after the Start Time of this IE within the current frame. 



Table 244— OFDM DL-MAP dummy IE format 



Syntax 


Size 


Notes 


Dummy _IE() { 






Extended DIUC 


4 bits 


0x05... OxOF 


Length 


4 bits 


0..15 


Unspecified data 


variable 


The "Length" field specifies the size of this 
field in bytes 


} 







8.3.6.3 UL-MAP IE format 

The UL-MAP IE defines the physical parameters and the start time for uplink PHY bursts. The format of 
UL-MAP elements is shown in Table 245. Appearance of the Extended UIUC, means that the UL-MAP IE 
contains information that conforms to the format described in 8.3.6.3.4. The BS shall not assign, to any 
given SS, two or more overlapping subchannelized allocations in time. An HFDD SS for which a DL MAP 
IE and UL MAP IE overlap in time shall use the UL allocation and discard DL traffic during the overlapping 
period. 
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Table 245 — OFDM UL-MAP IE format 



Syntax 


Size 


Notes 


UL-MAPJEO { 






CID 


16 bits 




Start Time 


1 1 bits 




Subchannel Index 


5 bits 




UIUC 


4 bits 




Duration 


10 bits 


in OFDM symbols 


Midamble repetition interval 


2 bits 


ObOO: Preamble only 

ObOl: Midamble after every 8 data symbols 

II r\ III* fV fx iHo mKlo O t\ a r oi/ar\f 1 /C /-Into r» » fmUAl r» 

uoiu. ivnudniDie drier every 10 aaia symoois 
Obll: Midamble after every 32 data symbols 


. if (UIUC ==4) 






Focused_ContentionJE() 


16 bits 




if (UIUC == 13) 






Subchanneli zed_Network_Entry_IE() 


12 bits 




if (UIUC == 15) 






UL_ExtendedJEO 


variable 


See subclauses following 8.3.6.3.4 


Padding nibble, if needed 


4 bits 


Completing to nearest byte, shall be set to 0x0 


} 







CD) 

Represents the assignment of the IE to a unicast, multicast, or broadcast address. When specifically 
addressed to allocate a bandwidth grant, the CID shall be the Basic CID of the SS. 
UIUC 

A 4-bit UIUC shall be used to define the type of uplink access and the burst type associated with 
that access. A Burst Descriptor shall be included into an UCD message for each UIUC that is to be 
used in the UL-MAP. The UIUC shall be one of the values defined in Table 246. 
Start Time 

Indicates the start time, in units of symbol duration, relative to the Allocation Start Time given in 
the UL-MAP message. The end of the last allocated burst is indicated by allocating an End of Map 
burst (CID = 0 and UIUC = 14). 
Duration 

Indicates the duration, in units of OFDM symbols, of the allocation. The duration is inclusive of the 
preamble, the midambles and the postamble, contained in the allocation. 
Subchannel Index 
See Table 213 

Midamble Repetition Interval 

Indicates the preamble repetition interval in OFDM symbols. When the last section of symbol after 
the last midamble is higher than half the midamble repetition interval (i.e., 4, 8, 16 for ObOl, ObOlO, 
Obi 1) a postamble shall be added at the end of the allocation. 
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8.3.6.3.1 UIUC allocations 

Table 246 contains the UIUC values used in the UL-MAP_IE(). 



Table 246— OFDM UIUC values 



UIUC 


Usage 


0 


reserved 


1 


Initial ranging 


2 


REQ Region Full 


3 


REQ Region Focused 


4 


Focused Contention IE 


5-12 


Burst Profiles 


13 


Subchannelization 
network entry 


14 


End of Map 


15 


Extended UIUC 



8.3.6.3.2 UL-MAP focused contention IE format 

Table 247 defines the UL-MAP IE for allocation of bandwidth for an SS that requested bandwidth using 
Focused Contention Reservation Requests (see 6.3.6.4). This UL-MAP IE is identified by UIUC = 4 (see 
Table 246). An SS responding to a bandwidth allocation using the Focused Contention IE shall start its burst 
with a short preamble (see 8.3.3.6) and use only the most robust mandatory burst profile in that burst. 



Table 247— OFDM focused contention IE format 



Syntax 


Size 


Notes 


Focused_ContentionJE() { 






Frame Number Index 


4 bits 




Transmit Opportunity Index 


3 bits 




Contention Channel Index 


6 bits 




Contention Code Index 


3 bits 




} 







Frame Number Index 

Identifies the frame in which the network entry request, which this message responds to, was 
transmitted. The four least significant bits of the frame number are used as the frame number index. 
Transmit Opportunity Index 

Index number of the Transmit Opportunity (used in the Bandwidth Request) that this message is 
responding to. The Transmit Opportunities are numbered from 0x0 to 0x7, where Transmit 
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Opportunity 0x0 indicates the first Transmit Opportunity in the frame pointed by the Frame 
Number Index. 
Contention Channel Index 

Index number of the Contention Channel (used in the Bandwidth Request) that this message is 
responding to. 
Contention Code Index 

Index number of the Contention Code (used in the Bandwidth Request) that this message is 
responding to. 

8.3.6.3.3 Subchannelized network entry IE 

Table 248 defines the UL-MAP IE for allocation of bandwidth in response to a subchannelized network 
entry signal (See 8.3.7.2). This UL-MAP IE is identified by UIUC = 13 in the subchannelized section of the 
UL-MAP. An SS responding to a bandwidth allocation using the Subchannelized Network entry IE shall 
start its burst with a short preamble (see 8.3.3.6) and use only the most robust mandatory burst profile in that 
burst. 



Table 248 — Subchannelized network entry IE format 



Syntax 


Size 


Notes 


Subchannelized_Network_Entry_IE() { 






Frame Number Index 


4 bits 




Transmit Opportunity Index 


4 bits 




Contention Subchannel 


4 bits 




} 







Frame Number Index 

Identifies the frame in which the network entry request, which this message responds to, was 
transmitted. The four least significant bits of the frame number are used as the Frame Number 
Index. 

Transmit Opportunity Index 

Index number of the Transmit Opportunity that was used in the network entry, within the frame 
pointed by the Frame Number Index. 
Contention Subchannel 

The number of the subchannel that was used for network entry. The contention subchannels are 
numbered from 0 to OxF and this number (n) represents the subchannel index (t) as specified in 
Table 213 according to i = 2*n + L 
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8.3.6.3.4 UL-MAP extended IE format 

A UL-MAP IE entry with a UIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 249. A station shall ignore an extended IE entry with an extended UIUC 
value for which the station has no knowledge. In the case of a known extended UIUC value but with a length 
field longer than expected, the station shall process information up to the known length and ignore the 
remainder of the IE. 



Table 249— OFDM UL-MAP extended IE format 



Syntax 


Size 


Notes 


UL.Extended JE() { 






Extended UIUC 


4 bits 


OxOCLOxOF 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







8.3.6.3.5 UL-MAP power control IE format 

When a power change for the SS is needed, UIUC = 15 is used with extended UIUC set to 0x00 and with 
8-bit Power control value as shown in Table 250. The power control value is an 8-bit signed integer 
expressing the change in power level (in 0.25 dB units) that the SS should apply to correct it's current 
transmission power. 

The CID used in the IE should be the Basic CID of the SS. 



Table 250 — OFDM power control IE format 



Syntax 


Size 


Notes 


Power_Control JE() { 






Extended UIUC 


4 tots 


Fast power control = 0x00 


Length 


4 bits 


Length = 1 


Power control 


8 bits 


Signed integer, which expresses the change in 
power level (in 0.25 dB units) that the SS should 
apply to correct its current transmission power. 


} 







8.3.6.3.6 UL-MAP AAS IE format 

Within a frame, the switch from non-AAS to AAS-enabled traffic is marked by using the UIUC = 15 with 
the AAS_IE() to indicate that the subsequent allocation until the end of the frame shall be for AAS traffic. 
When used, the CID in the UL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts 
shall all start with the short preamble. Stations not supporting the AAS functionality shall ignore the portion 
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of the frame marked for AAS traffic. The AAS_IE() shall not be used in AAS private map messages. 

Table 251— OFDM AAS UL IE format 



Syntax 


Size 


Notes 


AAS JEO { 






Extended UIUC 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x00 


} 







8.3.6.3.7 UL-MAP Physical Modifier IE 

The Physical Modifier Information Element indicates that the subsequent allocations shall utilize a preamble 
and midambles, which are cyclically delayed in time by M samples, meaning that the waveform transmitted 
during these training symbols shall be as shown in Equation (84): 



s{t) = Re 



c k xe 



2jKkAf(t-T g -M/F s ) 



* = -"use*'* 



(84) 



where 



is the time, elapsed since the beginning of the OFDM symbol, with 0<t<T s . 



The PHYMODJJLJE can appear anywhere in the UL map, and it shall remain in effect until another 
PHYMOD_UL_IE is encountered, or until the end of the UL map. 



Table 252— OFDM UL-MAP Physical Modifier IE format 



Syntax 


Size 


Notes 


PHYMOD_UL_IE() { 






Extended UIUC 


4 bits 


PHYMOD = 0x01 


Length 


4 bits 


Length = 1 


Preamble Time Shift 


8 bits 


Preamble time shift 


} 







Preamble Time Shift 

The parameter indicating how many samples of cyclic shift are introduced into the training symbols 
of the following allocations [M in Equation (84)]. 



Copyright ©2004 IEEE. All rights reserved. 



471 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



8.3.6.3.8 UL-MAP dummy IE format 

An SS shall be able to decode the UL-MAP Dummy IE. A BS shall not transmit this IE (unless under test). 



Table 253— OFDM UL-MAP dummy IE format 



Syntax 


Size 


Notes 


Dummy_IE() { 






Extended UIUC 


4 bits 


0x03..0x0F 


Length 


4 bits 


0..15 


Unspecified data 


variable 


The "Length" field specifies the size of this 
field in bytes ' 


} 







8.3.6.4 AAS-FBCK-REQ/RSP message bodies 

The AAS-FBCK-REQ/RSP messages are used to request and return measurements that assist beam forming 
in AAS systems. The format of the AAS-FBCK-REQ message body is shown in Table 254. 



Table 254— OFDM AAS Feedback Request message body 



Syntax 


Size 


Notes 


OFDM-AAS-FBCK-REQ_Message_Body() { 






Frame Number 


8 bits 




Start time 


11 bits 




Feedback Request Counter 


3 bits 




Frequency measurement resolution 


2 bits 




} 







Frame Number 

The least significant bits of the frame number of the burst on which the measurement shall be 
performed. Shall always point to a future frame. 
Start time: 

Indicates the start time, in units of symbol duration, of the burst on which to perform the 
measurement. Shall be relative to the start of the frame pointed to by the "Frame Number" field. 
Feedback Request Counter 

Increases every time an AAS-FBCK-REQ is sent to the SS. Individual counters shall be maintained 
for each SS. The value 0 shall not be used. 
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Frequency measurement resolution 

Indicates the frequency measurement points to report on. 

ObOO : Carriers -100, -96, -92, -88, -84, -80, -76, -72, -68, -64, -60, -56, -52, -48, -44, -40, -36, -32, 
-28, -24, -20, -16, -12, -8, -4, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 68, 72, 76, 
80, 84, 88, 92, 96, 100 

ObOl : Carriers -100, -92, -84, -76, -68, -60, -52, -44, -36, -28, -20, -12, -4, 4, 12, 20, 28, 36, 44, 52, 
60, 68, 76, 84, 92, 100 

OblO : Carriers -100, -84, -68, -52, -36, -20, -4, 4, 20, 36, 52, 68, 84, 100 
Obi 1 : Carriers -100, -68, -36, -4, 4, 36, 68, 100 

The measurements shall be transmitted in order of increasing frequency index. 
The format of the AAS-FBCK-RSP message body is shown in Table 255. 



Table 255— OFDM AAS Feedback Response message body 



Syntax 


Size 


Notes 


OFDM-AAS-FBCK-RSP_Message_Body() { 






Frame number 


8 bits 




Start time 


11 bits 




Feedback Request Counter 


3 bits 




Frequency measurement resolution 


2 bits 


Indicates the frequency measurement 
points as defined in Table 254. 


for 0=0; /<Number of Frequencies; /++){ 




Number of frequencies is either 50, 26, 
14, or 8 as appropriate and depending on 
the value of the Frequency measurement 
resolution field. 


Re(Frequency_value[/]) 


8 bits 




Im(Frequency_value[/]) 


8 bits 




} 






RSSI mean value 


8 bits 




CINR mean value 


8 bits 




} 







Frame number 

The least significant bits of the frame number of the burst on which the measurement was 
performed. Shall always point to a past frame. 
Start time 

Indicates start time, in units of symbol duration, of the burst on which the measurement was 
performed. Shall be relative to the start of the frame pointed to by the "frame number" field. 
Feedback Request Counter 

Counter from the AAS-FBCK-REQ messages to which this is the response. The value 0 indicates 
that the response is unsolicited. In this case, the measurement corresponds to the preceding frame. 
Frequency Measurement Resolution 
Indicates the frequency measurement points reported on. 
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Number of Frequencies 

The number of frequencies to be reported and as implied by the Frequency measurement resolution 
field. 

Re( Frequency_value[i] ) and Im( Frequency _va!ue[i] ) 

The real (Re) and imaginary (Im) part of the measured amplitude on the frequency measurement 
point (low to high frequency) in signed integer fixed point format ( [±][2 bits].[5 bits]). 
RSSI mean value 

The mean RSSI as measured on the element pointed to by data measurement type, frame number, 
and number of frames in the corresponding request. The RSSI is quantized as described in 8.3.9.2. 
When the AAS feedback response is unsolicited, this value corresponds to preceding frame. 
CINR mean value 

The mean CINR as measured on the element pointed to by data measurement type, frame number, 
and number of frames in the corresponding request. The RSSI is quantized as described in 8.3.9.2. 
When the AAS feedback response is unsolicited, this value corresponds to preceding frame. 

8.3.6.5 AAS-BEAM-REQ/RSP message 

The AAS Beam Request/Response messages shall be used by a system supporting AAS. This message 
serves to request channel measurement that will help in adjusting the direction of the adaptive array. This 
shall be used in conjunction with the AAS preamble. 



Table 256— AAS Beam request message format 



Syntax 


Size 


Notes 


AAS_BEAM_REQ_message format(){ 






Management message type = 47 


8 bits 




Frame number 


8 bits 




Feedback request number 


3 bits 




Measurement Report Type 


2 bits 


ObOO: BEAM_REP_IE() 
Otherwise: Reserved 


Resolution parameter 


3 bits 




Beam bit mask 


4 bits 


A bit corresponds to a requested report on 
the beam 


reserved 


4 bits 


Shall be set to zero 


} 







Frame Number 

The eight least significant bits of the frame Number in which to perform the measurement. 
Feedback Request Counter 

Every time an AAS-BEAM-REQ is sent to the SS. Individual counters shall be maintained for each 

SS. The value 0 shall not be used. 
Measurement report type 

The report type to be used. 
Beam Bit Mask 

A bit value of 1 signifies that the corresponding beam is to be reported on. 
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Table 257— AAS Beam response message format 



Syntax 


Size 


Notes 


AAS_BEAM_RSP_message format(){ 






Management message type = 48 


8 bits 




Frame number 


8 bits 




Feedback request number 


3 bits 




Measurement Report Type 


2 bits 


ObOO: BEAM_REP_IE() 
Otherwise: Reserved. 


Resolution parameter 


3 bits 




Beam bit mask 


4 bits 


A bit corresponds to a requested report on 
the beam 


reserved 


4 bits 


Shall be set to zero 


if (Measurement Report Type==0) 






AAS_BEAM_REP_IEO 






} 






RSSI mean value 


8 bits 




CINR mean value 


8 bits . 




} 







Frame Number 

The eight least significant bits of the Frame Number in which to perform the measurement. If the 
message is unsolicited corresponds to the previous frame. 
Feedback Request Counter 

Counter from the AAS-BEAM-REQ messages to which this is the response. The value 0 indicates 

that the response is unsolicited. 
Measurement report type 

The report type to be used. 
Beam Bit Mask 

A bit value of 1 signifies that the corresponding beam is to be reported on. 
RSSI mean value 

The mean RSSI as measured on the element pointed to by data measurement type, frame number, 
and number of frames in the corresponding request. The RSSI is quantized as described in 8.3.9.2. 
When the AAS feedback response is unsolicited, this value corresponds to preceding frame. 
CINR mean value 

The mean CINR as measured on the element pointed to by data measurement type, frame number, 
and number of frames in the corresponding request. The RSSI is quantized as described in 8.3.9.2. 
When the AAS feedback response is unsolicited, this value corresponds to preceding frame. 
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The AAS beam pattern report IE shall be used in conjunction with the AAS_BEAM_REQ/RSP messages. 
This report IE contain the frequency response of the beams transmitted during the AAS ^preamble of the 
corresponding frame, only the beams which corresponds to the Beam Bit mask are reported. The resolution 
parameter is interpreted as follows: 

resolution parameter =0b000 => report every 4th subcarrier 
resolution parameter ==0b001 => report every 8th subcarrier 
resolution parameter ==0b010 => report every 16th subcarrier 
resolution parameter ==0b011 => report every 32th subcarrier 
resolution parameter ==0bl00 => report every 64th subcarrier 

Measurement points shall be on the frequencies corresponding to the negative subcarrier offset indices - 
Nusedf 2 P lus n times the i ndicated subcarrier resolution and corresponding to the positive subcarrier offset 
indices N used /2 minus n times the indicated subcarrier resolution where n is a positive integer. 



Table 258— AAS Beam report IE format 



Syntax 


Size 


Notes 


AAS BEAM REP IE_message-format() { 






for (m=0; m < NumberOfBeams; m++) { 






for (n=0; n< NumberOfFrequencies; «++){ 






Re {Frequency_value_beam[m,n] 


8 bits 




Im {Frequency_value_beam[m,n] 


8 bits 




} 






} 






} 







Re( Frequency_value_beam[m^] ) and Im( Frequency_value_beam[m,n] ) 

The real (Re) and imaginary (Im) part of the measured amplitude on the frequency measurement 
point n (low to high frequency) from beam m in signed integer fixed point format 
([±][2bits].[5bits]). 



8.3.7 Control mechanisms 

8.3.7.1 Synchronization 

8.3.7.1 .1 Network synchronization 

For TDD and FDD realizations, it is recommended (but not required) that all BSs be time synchronized to a 
common timing signal. In the event of the loss of the network timing signal, BSs may continue to operate 
and shall automatically resynchronize to the network timing signal when it is recovered. The synchronizing 
reference shall be a 1 pps timing pulse. A 10 MHz frequency reference may also be used. These signals are 
typically provided by a GPS receiver. 
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For both FDD and TDD realizations, frequency references derived from the timing reference may be used to 
control the frequency accuracy of Base-Stations provided that they meet the frequency accuracy 
requirements of 8.3.12. This applies during normal operation and during loss of timing reference. 

8.3.7.2 Ranging 

There are two types of ranging processes — initial ranging (see 6.3.9.5) and periodic ranging (see 6.3.10). 
Initial ranging (coarse synchronization) and power are performed during two phases of operation; during 
(re)registration and when synchronization is lost; and secondly, during transmission on a periodic basis. 
Initial ranging uses the initial ranging contention-based interval, which requires a long preamble. The 
periodic ranging uses the regular uplink burst. 

During registration, a new subscriber registers during the random access channel, and, if successful, it is 
entered into a ranging process under control of the BS. The ranging process is cyclic in nature where default 
time and power parameters are used to initiate the process followed by cycles where (re)calculated 
parameters are used in succession until parameters meet acceptance criteria for the new subscriber. These 
parameters are monitored, measured and stored at the BS, and transmitted to the subscriber unit for use 
during normal exchange of data. During normal exchange of data, the stored parameters are updated in a 
periodic manner based on configurable update intervals to ensure that changes in the channel can be 
accommodated. The update intervals shall vary in a controlled manner on a subscriber unit by subscriber 
unit basis. Initial ranging transmissions shall use a long preamble and the most robust mandatory burst 
profile. 

Ranging on re- registration follows the same process as new registration. 

Regardless of duplexing type, the appropriate duration of the Initial Ranging slot used for initial system 
access depends on the intended cell radius. 

SSs that compute their PTX_lR_max t0 exceed their maximum power level and SSs that have attempted initial 
ranging with the maximum power level using RNG-REQ may, if the BS supports subchannelization, attempt 
initial ranging in an initial ranging slot using the following burst format: 

The SS shall transmit the long preamble as defined in 8.3.3.6. This shall be followed by two identical 
symbols containing a subchannelized preamble, on a single randomly selected subchannel. Note that the 
long preamble is transmitted on the entire BW while the subchannelized preamble is transmitted on 1/16 of 
the BW. 

The long preamble and the subchannelized preamble shall be transmitted using the same total power. As a 
result the spectral density of the long preamble shall be lower by a factor of 16 (about 12dB) than the power 
spectral density of the subchannelized preamble. 

The BS need only detect that energy is sent on a single subchannel and may respond by allocating a single 
subchannel identifying the SS by the Transmit Opportunity, Frame Number and ranging subchannel in 
which the transmission was received. The allocation is accomplished by sending an UL-MAP IE containing 
a Subchannelized_Network_Entry_IE (see 8.3.6.3.3) and transmitted using the Initial Ranging CID. The 
allocated bandwidth shall be big enough as to contain at least one RNG-REQ message. 

A SS attempting subchannelized initial ranging shall use its maximum power setting for the initial ranging 
burst. 
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8.3.7.2.1 Initial Ranging in AAS systems 

A BS supporting the AAS option may allocate in the uplink subframe an AAS alert slot for AAS SSs that 
have to initially alert the BS of their presence. This period shall be marked as Initial-Ranging (UIUC=1), but 
shall be marked by an AAS initial ranging CID such that no non-AAS subscriber (or AAS subscriber that 
can decode the UL-MAP message) uses this interval for Initial Ranging. Additionally, this period shall be 
marked using AAS map (see Table 251). The SS shall transmit the long preamble as defined in 8.3.3.6. This 
shall be followed by a burst carrying the AAS_NW_ENTRY_REQ message (see Table 259). This burst shall 
use the most robust mandatory rate. 

The BS may respond to the network entry request by transmitting a RNG-RSP message indicating the 
required changes to the ranging parameters. The SS is identified by specifying the transmit opportunity and 
the entry code of the AAS_NW_ENTRY_REQ message. When transmitting the response, the BS may use 
the feedback information embedded in the AAS_NW_ENTRY_REQ to direct the beam to the SS. 

The BS may additionally assign subchannelized AAS alert slot for SSs supporting subchannelization. AAS 
SSs that have attempted initial ranging with the maximum power level using AAS_NW_ENTRY_REQ may 
attempt initial ranging in the subchannelized AAS alert slot. The SS shall transmit the long preamble as 
defined in 8.3.3.6. This shall be followed by subchannelized burst carrying the 
AAS_SBCH_NW_ENTRY_REQ message (see Table 260). This message shall be sent on the subchannel 
indicated by the UL-MAP information element used to allocate the ranging period. 

Table 259— OFDM A AS_N W_E NTRY_ R EQ format 



Syntax 


Size 


Notes 


AAS_NW_ENTRY_REQ() { 






Network entry code 


4 bits 


A randomly selected code. 


Measurement frame index 


4 bits 


The 4 LSB of the frame number to 
which the beam measurements refer. 


for (i=0; i<4; i++){ 






Re(beam_value[i]) 


8 bits 




Im(beam_value[i]) 


8 bits 




} 






RSSI mean value 


8 bits 




HCS 


8 bits 




} 







Network entry code 
A 4 bit number selected at random. 
Measurement frame index 

The 4 LSB of the frame number to which the beam measurements refer. 
Re( beam_value[m] ) and Im(beam_value[ro] ) 

The real (Re) and imaginary (Im) part of the measured amplitude of beam m in signed integer fixed 
point format ( [±][2 bits]. [5 bits]). These values are measured on the AAS preamble pointed to by 
measurement frame index. A single value shall be used for the entire bandwidth. 
RSSI 

The RSSI of the AAS preamble information pointed to by measurement frame index. This value is 
averaged over the four beams. The RSSI value shall be quantized as in 8.3.9.2. 
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Table 260— OFDM SBCH_AAS_NW_ENTRY_REQ format 



Syntax 


Size 


Notes 


SBCH_AAS_NW_ENTRY_REQ(){ 






Network entry code 


4 bits 


A randomly selected code. ■ 


Phase offset 1 


4 bits 


The mean phase offset of beam 1 
relative to beam 0. 4-bit signed 
number, in units of 360716. 


Phase offset 2 


4 bits 


The mean phase offset of beam 2 
relative to beam 0. 4-bit signed 
number, in units of 360716. 


Phase offset 3 


4 bits 


The mean phase offset of beam 3 
relative to beam 0. 4-bit signed 
number, in units of 360716. 


Measurement frame index 


lbit 


0: Phase information corresponds to 
beams in previous frame 

1: Phase information corresponds to 
beams in one before previous 
frame. 


RSSI mean value 


5 bits 




} 







Network entry code 
A 4-bit number selected at random. 
Phase offset 1...3 

The phase offsets that are required to be performed by the BS, in order to from the beam towards 
the SS. The phase offsets are estimated using the AAS preamble and are given relative to the first 
beam. 

Measurement frame index 

Indicates whether the phase information corresponds to the previous frame or to the one before the 
previous frame. 
RSSI 

The RSSI of the AAS preamble information pointed to by measurement frame index. This value is 
averaged over the four beams. This value shall be quantized in 2 dB increments, ranging from -110 
dBm (encoded 0x00) to -48 dBm (encoded OxlF). Values outside this range shall be assigned the 
closest extreme value within the scale. 

8.3.7.3 Bandwidth requesting 

There may be two types of REQ Regions in a frame. These two types are REQ Region-Full and REQ 
Region-Focused. 

In a REQ Region-Full, when subchannelization is not active, each Transmit Opportunity shall consist of a 
short preamble and one OFDM symbol using the most robust mandatory burst profile. When 
subchannelization is active, the allocation is partitioned into Transmission Opportunities (TOs) both in 
frequency and in time. The width (in subchannels) and length (in OFDM symbols) of each transmission 
opportunity (TO) is defined in the UCD message defining (see Table 352). The transmission of an SS shall 
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contain a subchannelized preamble corresponding to the TO chosen, followed by data OFDM symbols using 
the most robust mandatory burst profile. 

In a REQ Region-Focused, a station shall send a short code over a Transmit Opportunity that consists of four 
subcarriers by two OFDM symbols. Each Transmit Opportunity within a frame shall be indexed by 
consecutive Transmit Opportunity Indices. The first occurring Transmit Opportunity shall be indexed 0. 

All SS shall be capable of the Full Contention Transmission. Capability of the Focused Contention 
Transmission is optional. The SS shall follow the backoff procedure as described in 6.3.8. 

8.3.7.3.1 Parameter selection 

The SS shall examine the ULJvlAP message for a future frame and select (in accordance with 6.3.8) a future 
REQ Region during which to make its request. If Focused Contention Supported = 1 was returned by the BS 
in SBC-RSP message during SS initialization and if the SS is capable of focused contention, it may choose 
either a REQ Region-Full or REQ Region-Focused. Otherwise, it shall choose a REQ Region-Full. 

If the chosen REQ Region is a REQ Region-Focused, the SS shall also select a contention code from 
Table 261 and similarly a contention channel from Table 262. The contention channel shall be selected from 
Table 261 based upon a random selection with equal probability among the group of possible contention 
channels that are consistent with the allocation, as indicated in Table 262. The indices {-100 to +100} in the 
body of Table 262 refer to the subcarrier indices as defined in 8.3.2.4. The number of contention codes that 
can be used by a subchannelized capable SS is denoted by C SE . The contention code shall be selected at 
random with equal probability from the appropriate subset of codes in Table 261 according to the value of 

c se- 

If the BS supports subchannelization, the last C SE contention codes shall only be used by subchannelization- 
enabled SSs that wish to receive a subchannelized allocation. In response, the BS may provide the requested 
allocation as a subchannelized allocation; may provide the requested allocation as a full (default) allocation, 
or may provide no allocation at all. The value of C SE is transmitted in the UCD channel encoding TLV mes- 
sages. The default value of C SE is 0. 

A BS that supports Focused Contention may allocate the Focused Contention region based upon the BSID, 
thereby reducing the probability of interference from SSs operating in nearby cells operating on the same 
frequency. 

Any Focused Contention region allocation shall be restricted to an even Subchannel Index (meaning that it 
be no finer than a 1/8 subchannel— see Table 213), providing between 6 and 48 contention channels. 
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Table 261— OFDM Contention codes 



Contention 
code index 


BitO 


Bitl 


Bit 2 


Bit 3 


0 


1 


1 


1 


1 


1 


1 


-1 


1 


-1 


2 


1 


1 


-1 


-1 


3 


1 


-1 


-1 


1 


4 


-1 


-1 


-1 


-t 


5 


-1 


1 


-1 


1 


6 


-1 


-1 


1 


1 


7 


-1 


1 


1 


-1 



Table 262— OFDM Contention channels 



Contention 
cnctnnci lnaex 


Frequency 
offset 
index 0 


Frequency 
offset 
index 1 


Frequency 
offset 
index 2 


Frequency 
offset 
index 3 


Contention 
Channel 
belongs to 
subchannel 
(See Table 213) 


0 


-100 


-37 


1 


64 


ObOOOlO 


1 


-99 


-36 


2 


65 


ObOOOlO 


2 


-98 


-35 


3 


66 


ObOOOlO 1 


3 


-97 


-34 


4 


67 


ObOOOlO 


4 


-96 


-33 


5 


68 


ObOOOlO 


5 


-95 


-32 


6 


69 


ObOOOlO 


6 


-94 


-31 


7 


70 


ObOOllO 


7 


-93 


-30 


8 


71 


ObOOllO 


8 


-92 


-29 


9 


72 


ObOOllO \ 


9 


-91 


-28 


10 


73 


ObOOllO 


10 


-90 


-27 


11 


74 


ObOOllO 


11 


-89 


-26 


12 


75 


ObOOllO 


12 


-87 


-50 


14 


51 


ObOlOlO 


13 


-86 


-49 


15 


52 


ObOlOlO 


14 


-85 


-48 


16 


53 


ObOlOlO 


15 


-84 


-47 


17 


54 


ObOlOlO 


16 


-83 


-46 


18 


55 


ObOlOlO 
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Table 262— OFDM Contention channels (continued) 



Contention 
channel index 


Frequency 
offset 
index 0 


Frequency 
offset 
index 1 


Frequency 
of&et 
index 2 


Frequency 
offset 
index 3 


Contention 
Channel 
belongs to 
subchannel 
(See Table 213) 


17 


-82 


-45 


19 


56 ! 


ObOlOlO 


18 


-81 


-44 


20 


57 


ObOlllO 


19 


-80 


-43 


21 


58 


ObOlllO 


20 


-79 


-42 


22 


59 


ObOlllO 


21 


-78 


-41 


23 


60 


ObOlllO 


22 


-77 


-40 ' 


24 


61 


ObOlllO 


23 


-76 


-39 


25 


62 


ObOlllO 


24 


-75 


-12 


26 


89 


OblOOlO 


25 


-74 


-11 


27 


90 , 


OblOOlO 


26 


-73 


-10 


28 


91 


OblOOlO 


27 


-72 


-9 


29 


92 


OblOOlO 


28 


-71 


-8 


30 


93 


OblOOlO 


29 


-70 


-7 


31 


94 


OblOOlO 


30 


-69 


-6 


32 


95 


OblOllO 


31 


-68 


-5 


33 


96 


Ob 10 110 


32 


-67 


-4 


34 


97 


OblOllO 


33 


-66 


-3 


35 


98 


OblOllO 


34 


-65 


-2 


36 . 


99 


OblOllO 


35 


-64 


-1 


37 


100 


OblOllO 


36 


-62 


-25 


39 


76 


ObllOlO 


37 


-61 


-24 


40 


77 


ObllOlO 


38 


-60 


-23 


41 


78 


ObllOlO 


39 


-59 


-22 


42 


79 


ObllOlO 


40 


-58 


-21 


43 


80 


ObllOlO 


41 


-57 


-20 


44 


81 


ObllOlO 


42 


-56 


-19 


45 


82 


ObllllO 


43 


-55 


-18 


46 


83 


ObllllO 


44 


-54 


-17 


47 


84 


ObllllO 


45 


-53 


-16 


48 


85 


ObllllO 


46 


-52 


-15 


49 


86 


ObllllO 


47 


-51 


-14 


50 


87 


ObllllO 
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8.3.7.3.2 Full Contention transmission 

If the chosen REQ Region is a REQ Region-Full, the SS shall transmit the short preamble as defined in 
8.3.3.6, followed by a Bandwidth Request MAC Header as defined in 6.3.2.1.2. 

If the Full Contention allocation appears in subchannelized region, the allocation is partitioned into 
transmission opportunities (TOs) both in frequency and in time. The width (in subchannels) and length (in 
OFDM symbols) of each transmission opportunity is defined in the UCD message defining UIUC = 2. The 
transmission of an SS shall contain a subchannelized preamble corresponding to the TO chosen, followed by 
data OFDM symbols using the most robust mandatory burst profile. 

8.3.7.3.3 Focused Contention transmission 

The REQ Region-Focused bandwidth requesting mechanism consists of two phases. The Phase- 1 is that an 
SS requesting bandwidth sends a signal to the BS in the uplink TO of REQ Region Focused identified by 
UIUC = 3. One REQ Region Focused uplink interval with UIUC = 3 shall be four subcarriers by two OFDM 
symbols. The Phase- 1 bandwidth requesting signal transmission is described in this subclause. Following 
the Phase-1, the BS may include in its UL-MAP an allocation for the SS using UIUC = 4 and the 
Focused_ContentionJE as defined in Table 247. The SS is identified in this Focused_Contention_IE by the 
Frame Number index, Transmit Opportunity index, Contention Channel index, and Contention Code index 
that the SS used to send the Phase-1 bandwidth requesting signal. The Phase-2 is that the SS requesting 
bandwidth responds to this UL-MAP allocation with a bandwidth request MAC header as defined in 
6.3.2.1.2. The Phase-2 uplink interval with UIUC = 4 shall consist of a short preamble and shall have the 
duration indicated by the relevant field of the UL-MAP_IE() and shall use the most robust mandatory burst 
profile. 

If the chosen REQ Region is a REQ Region-Focused, after choosing its four parameters, the SS shall 
transmit, during the chosen Transmit Opportunity in the chosen frame, four subcarriers that comprise the 
chosen contention channel. The amplitude of all other subcarriers shall be zero. 

During both OFDM symbols, the amplitude of each of the four subcarriers shall be boosted somewhat above 
its normal amplitude, i.e., the amplitude used during a noncontention OFDM symbol, including the current 
power-control correction. The boost in dB shall equal the value of the Focused Contention Power Boost 
parameter in the current UCD. 

During the first OFDM symbol of the Transmit Opportunity, the phase of the four subcarriers is not 
specified. 

During the second OFDM symbol of the Transmit Opportunity, the phases shall depend on the 
corresponding bit in the chosen contention code, and the phase transmitted during the first OFDM symbol 
on the same subcarrier. If the code bit is +1, the phase shall be the same as that transmitted during the first 
OFDM symbol. If the code bit is -1, the phase shall be inverted, 180 degrees with respect to the phase 
transmitted during the first OFDM symbol. 

8.3.7.4 Power control 

As with frequency control, a power control algorithm shall be supported for the uplink channel with both an 
initial calibration and periodic adjustment procedure without loss of data. The objective of the power control 
algorithm is to bring the received power density from a given subscriber to a desired level. The received 
power density is defined as total power received from a given subscriber divided by the number of active 
subcarriers. When subchannelization is not employed, the number of active subcarriers is equal for all the 
subscribers and the power control algorithm shall bring the total received power from a given subscriber to 
the desired level, the base station shall be capable of providing accurate power measurements of the 
received burst signal. This value can then be compared against a reference level, and the resulting error can 
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be fed back to the SS in a calibration message coming from the MAC. The power control algorithm shall be 
designed to support power attenuation due to distance loss or power fluctuations at rates to 30 dB/second 
with depths of at least 10 dB. The exact algorithm implementation is vendor-specific. The total power 
control range consists of both a fixed portion and a portion that is automatically controlled by feedback. The 
power control algorithm shall take into account the interaction of the RF power amplifier with different burst 
profiles. For example, when changing from one burst profile to another, margins should be maintained to 
prevent saturation of the amplifier and to prevent violation of emissions masks. 

When subchannelization is employed, the SS shall maintain the same transmitted power density unless the 
maximum power level is reached. That is, when the number of active subchannels allocated to a user is 
reduced, the total transmitted power shall be reduced proportionally by the SS, without additional power 
control messages. When the number of subchannels is increased the total transmitted power shall also be 
increased proportionally. However, the transmitted power level shall not exceed the maximum levels 
dictated by signal integrity considerations and regulatory requirements. Subscriber stations shall report the 
maximum available power, and the normalized transmitted power. 

Subscriber stations shall report the maximum available power and the current transmitted power. These 
parameters may be used by the Base station for optimal assignment of coding schemes and modulations and 
also for optimal allocation of subchannels. The algorithm is vendor- specific. These parameters are reported 
in the SBC-REQ message. The current transmitted power shall also be reported in the REP-RSP message if 
the relevant flag in the REP-REQ message has been set. 

The current transmitted power is the power of the burst that carries the message. The maximum available 
power is reported for BPSK, QPSK QAM 16, and QAM64 constellations. The current transmitted power and 
the maximum power parameters are reported in dBm. The parameters are quantized in 0.5 dBm steps 
ranging from -64 dBm (encoded 0x00) to 63.5 dBm (encoded OxFF). Values outside this range shall be 
assigned the closest extreme. SSs that do not support QAM64 shall report the value of 0x00 in the maximum 
QAM64 power field. 

8.3.8 Transmit diversity: Space-Time Coding (optional) 

STC (see Alamouti [Bl]) may be used on the downlink to provide second order (Space) transmit diversity. 

There are two transmit antennas on the BS side and one reception antenna on the SS side. This scheme 
requires Multiple Input Single Output channel estimation. Decoding is very similar to maximum ratio 
combining. 

Figure 211 shows STC insertion into the OFDM chain. Each Tx antenna has its own OFDM chain, but they 
have the same Local Oscillator for synchronization purposes. 

Both antennas transmit in the same time two different OFDM data symbols. Transmission is performed 
twice to decode and to get second order diversity. Time domain (Space-Time) repetition is used. 

8.3.8.1 Multiple input single output channel estimation and synchronization 

Both antennas transmit in the same time, and they share the same Local Oscillator. Thus, the received signal 
has exactly the same auto-correlation properties as for a single antenna. So, time and frequency coarse and 
fine estimation can be performed in the same way as for a single antenna. The scheme requires MISO 
channel estimation, which is provisioned by inserting an STC preamble, transmitted from both antennas, 
using the STCJE (see 8.3.6.2.5 and 8.3.3.6). 
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Figure 211— Illustration of STC 



8.3.8.2 STC encoding 



The basic scheme Alamouti [Bl] transmits two complex symbols sq and s\, using the multiple input single 
output channel (two Tx, one Rx) twice with channel vector values h Q (for antenna 0) and h x (for antenna 1). 

First channel use: Antenna 0 transmits s 0 , antenna 1 transmits s { . 

Second channel use: Antenna 0 transmits -j,* , antenna 1 transmits s 0 * . 

Receiver gets r 0 (first channel use) and ^(second channel use) and computes s 0 and s\ estimates: 



$o = V'o + V r i* 



*i = V- r <rV r i* 



(85) 
(86) 



These estimates benefit from second order diversity as in the lTx-2Rx Maximum Ratio Combining scheme. 
OFDM symbols are taken by pairs. The precoding operation, and consecutively the receive decoding [as 
described in Equation (85) and Equation (86)], is applied independently to same-numbered subcarriers in 
two consecutive OFDM data symbols. Note that the two OFDM symbols may belong to different PHY 
bursts and even use different constellations. An individual PHY burst may contain any integer number of 
symbols. The aggregate duration of all PHY bursts following the last STC preamble or between any two 
STC preambles shall be a multiple of 2. 

On a given pilot subcarrier, the same pilot symbol is used for the STC block. If the STC block consists of 
OFDM symbol k and k+1 and p s is the pilot symbol for pilot subcarrier s as derived for OFDM symbol k 
from 8.3.3.4.2, then the modulation on pilot subcarrier s during OFDM symbol k shall be p s on both antenna 
0 and 1. During OFDM symbol k+1, it shall be -p s on antenna 0 and p s on antenna 1. 

Figure 212 shows the STC scheme (note that only pilot subcarrier -88 is depicted). 

8.3.8.3 STC decoding 

The receiver waits for two symbols, and combines them on a subcarrier basis according to Equation (85) and 
Equation (86) in 8.3.8.2. 
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Figure 212— STC usage with OFDM 



8.3.9 Channel quality measurements 

8.3.9.1 Introduction 

RSSI and CINR signal quality measurements and associated statistics can aid in such processes as BS 
selection/assignment and burst adaptive profile selection. As channel behavior is time-variant, both mean 
and standard deviation are defined. Implementation of the RSSI and CINR statistics and their reports is 
mandatory. 

The process by which RSSI measurements are taken does not necessarily require receiver demodulation 
lock; for this reason, RSSI measurements offer reasonably reliable channel strength assessments even at low 
signal levels. On the other hand, although CINR measurements require receiver lock, they provide 
information on the actual operating condition of the receiver, including interference and noise levels, and 
signal strength. 

8.3.9.2 RSSI mean and standard deviation 

When collection of RSSI measurements is mandated by the BS, an SS shall obtain an RSSI measurement 
from the OFDM downlink preambles. From a succession of RSSI measurements, the SS shall derive and 
update estimates of the mean and the standard deviation of the RSSI, and report them via REP-RSP 
messages. 

Mean and standard deviation statistics shall be reported in units of dBm. To prepare such reports, statistics 
shall be quantized in 1 dB increments, ranging from ^0 dBm (encoded 0x53) to -123 dBm (encoded 0x00). 
Values outside this range shall be assigned the closest extreme value within the scale. 
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The method used to estimate the RSSI of a single message is left to individual implementation, but the 
relative accuracy of a single signal strength measurement, taken from a single message, shall be ± 2 dB, with 
an absolute accuracy of ± 4 dB. The specified accuracy shall apply to the range of RSSI values starting from 
6 dB below the sensitivity level of the most robust mode or -123 dBm (whichever is higher) up to -40dBm. 
In addition, the range over which these single-message measurements are measured should extend 3 dB on 
each side beyond the -40 dBm to -123 dBm limits for the final averaged statistics that are reported. 

One possible method to estimate the RSSI of a signal of interest at the antenna connector is given by 
Equation (87): 



RSSI = 10. 10 



?1.2567xl0Vr N ~ l 



(2 2B )R 



mW (87) 



n - 0 



where 



B is the ADC precision, number of bits of ADC, 

R is the ADC input resistance [Ohm], 

V c is the ADC input clip level [Volts], 

G rt is the analog gain from antenna connector to ADC input, 

Yj 0T Q[k,n] is the sample at the ADC output of I or Q-branch within signal k, 
N is the number of samples. 

The (linear) mean RSSI statistics (in mW), derived from a multiplicity of single messages, shall be updated 
using Equation (88), 

fori*] -1 . * [ ° ] * = ( U (88) 

{l-a nyg )\L RSSi [k-\] + a mg R[k] *>0 

where k is the time index for the message (with the initial message being indexed by k = 0, the next message 
by k = 1, etc.), R[k] is the RSSI in mW measured during message k, and a avg is an averaging parameter 
specified by the BS. The mean estimate in dBm shall then be derived from Equation (89). 

i ||W dBm I« - lOlog(iWfl) dBm (89) 

To solve for the standard deviation in dB, the expectation-squared statistic shall be updated using 
Equation (90), 



*RSSf 



\R[0]\ 2 k = 0 (9Q) 

( l - a avg )*^5/[* 1 1 + «av 8 l*[*3l 2 * > 0 

and the result applied to Equation (91). 

a «WdB = 51 °8(|*«sfM-(S««/[*])1) ' dB (91) 
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8.3.9.3 CINR mean and standard deviation 

When CINR measurements are mandated by the BS, an SS shall obtain a CINR measurement (implementa- 
tion-specific). From a succession of these measurements, the SS shall derive and update estimates of the 
mean and the standard deviation of the CINR, and report them via REP-RSP messages. 

Mean and standard deviation statistics for CINR shall be reported in units of dB. To prepare such reports, 
statistics shall be quantized in 1 dB increments, ranging from a minimum of -10 dB (encoded 0x00) to a 
maximum of 53 dB (encoded 0x3F). Values outside this range shall be assigned the closest extreme value 
within the scale. 

The method used to estimate the CINR of a single message is left to individual implementation, but the 
relative and absolute accuracy of a CINR measurement derived from a single message shall be ± 1 dB and 
± 2 dB, respectively. The specified accuracy shall apply to the range of CINR values starting from 3 dB 
below SNR of the most robust rate, to 10 dB above the SNR of the least robust rate. See Table 266. In 
addition, the range over which these single-packet measurements are measured should extend 3 dB on each 
side beyond the -10 dB to 53 dB limits for the final reported, averaged statistics. 

One possible method to estimate the CINR of a single message is to compute the ratio of the sum of signal 
power and the sum of residual error for each data sample, using Equation (92). 

£U[*,«]| 2 

CINR[« = N _ l n = 0 ( 92 ) 

£|r[M]-*[*,*]| 2 

n =0 

where r[k,n\ received sample n within message k\ s[k,n] the corresponding detected or pilot sample (with 
channel state weighting) corresponding to received symbol n. 

The mean CINR statistic (in dB) shall be derived from a multiplicity of single messages using Equation (93). 



A CINR dB W = 101og(Ocn«[«> ( 93 > 



where 



= | CINR[ ° ] * = ° < 94 > 

I (l-a avg )ilciNR[*-l] + otavgCINR[fe] *>0 

k is the time index for the message (with the initial message being indexed by k =0, the next message by k = 
1, etc.);CINR[A:] is a linear measurement of CINR (derived by any mechanism that delivers the prescribed 
accuracy) for message k; and a avg is an averaging parameter specified by the BS. 

To solve for the standard deviation, the expectation- squared statistic shall be updated using Equation (95), 



*cinr[*J 



CINR[0]| 2 k = 0 ( 95 ) 

'avg'-* CINr[* - + a avgl 



(1 " <W* 2 dNRr* " 11 + "avgl CINRMI' k > 0 



and the result applied to Equation (96). 

= 5log(|x 2 CINR [^-(iiciNRm) 2 |) ( % ) 



a 

CINR dB 
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8.3.1 0 Transmitter requirements 
8.3.10.1 Transmit power level control 

For an SS not supporting subchannelization, the transmitter shall support a monotonic power level control of 
30 dB minimum. For an SS supporting subchannelization, the transmitter shall support a monotonic power 
level control of 50 dB minimum. The minimum step size shall be no more than 1 dB. The relative accuracy 
of the power control mechanism is ±1.5 dB for step sizes not exceeding 30dB and ±3 dB for step sizes 
greater than 30 dB. For a BS, the transmitter shall support a monotonic power level control of 10 dB 
minimum. 

8.3.10.1.1 Transmitter spectral flatness 

The average energy of the constellations in each of the n spectral lines shall deviate no more than indicated 
in Table 263. The absolute difference between adjacent subcarriers shall not exceed 0.1 dB. 



Table 263— OFDM Spectral flatness 



Spectral lines 


Spectral flatness 


Spectral lines from -50 to -1 and +1 to +50 


± 2 dB from the measured energy averaged 
over all 200 active tones 


Spectral lines from -100 to -50 and 
+50 to +100 


+2/- 4d B from the measured energy averaged 
over all 200 active tones 



This data shall be taken from the channel estimation step. 

8.3.1 0.1 .2 Transmitter constellation error and test method 

To ensure that the receiver SNR does not degrade more than 0.5 dB due to the transmitter SNR, the relative 
constellation RMS error, averaged over subcarriers, OFDM frames, and packets, shall not exceed a burst 
profile dependent value according to Table 264. 

Table 264 — Allowed relative constellation error versus data rate 



Burst type 


Relative constellation error (dB) 


BPSK-1/2 


-13.0 


QPSK-1/2 


-16.0 


QPSK-3/4 


-18.5 


16-QAM-1/2 


-21.5 


16-QAM-3/4 


-25.0 


64-QAM-2/3 


-28.5 


64-QAM-3/4 


-31.0 
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The sampled signal shall be processed in a manner similar to an actual receiver, according to the following 
steps, or an equivalent procedure (IEEE Std 802. 11 a- 1999 [B29]): 

a) Start of frame shall be detected. 

b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing 
(with one sample resolution) shall be established. 

c) Coarse and fine frequency offsets shall be estimated. 

d) The packet shall be de-rotated according to estimated frequency offset. 

e) The complex channel response coefficients shall be estimated for each of the subcarriers. 

f) For each of the data OFDM symbols, transform the symbol into subcarrier received values, estimate 
the phase from the pilot subcarriers, de-rotate the subcarrier values according to estimated phase, 
and divide each subcarrier value with a complex estimated channel response coefficient. In the case 
of subchannelization transmission, the estimated channel coefficient of the nearest allocated subcar- 
rier shall be used for those subcarriers not part of the allocated subchannels. 

g) For each data-carrying subcarrier, find the closest constellation point and compute the Euclidean 
distance from it. In the case of subchannelization transmission, for data-carrying subcarriers not part 
of the allocated subchannels, the Euclidean distance shall be computed relative to 0+0j. 

h) Compute the RMS average of all errors in a packet. It is given by: 



EmT RMS = W f 2 



i = 1 



£ \ (I(ij,k) - I 0 (ij,k)) 2 + (GOV,*) - Q 0 VJ*)) 2 



**0 



(97) 



2 \i 0 VJ*) +Q 0 W« 



k = -N used /2 
**0 



where 



L P is the length of the packet, 

N f is the number of frames for the measurement, 

(I 0 (7,y,k), Q 0 (i,j,k)) denotes the ideal symbol point of the i* frame,/ 1 OFDM symbol of the frame, # h 
subcarrier of the OFDM symbol in the complex plane, 

(I(*j,k), Q(zj,k)) denotes the observed point of the I th frame, / h OFDM symbol of the frame, # h 

subcarrier of the OFDM symbol in the complex plane. 

8.3.10.2 Transmitter channel bandwidth and RF carrier frequencies 

For licensed bands, channel bandwidths allowed shall be limited to the regulatory provisioned bandwidth 
divided by any power of 2, rounded down to the nearest multiple of 250 kHz, resulting in a channel band- 
width no less than 1.25 MHz. 



If the resulting channel bandwidth is an odd multiple of 250 kHz, then for any band for which support is 
claimed, the RF carrier shall only be tunable to every odd multiple of 125 kHz within that band. If the 
resulting channel bandwidth is an even multiple of 250 kHz, then for any band for which support is claimed, 
the RF carrier shall only be tunable to every even multiple of 125 kHz within that band. For FDD systems, 
support shall be claimed separately for uplink and downlink. 
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For example, if the regulatory provisioned bandwidth is 14 MHz between 3400 and 3414 MHz, then the 
allowed channelled bandwidths are those shown in Table 265. 



Table 265 — Example of channelization for licensed bands 



Channelization (MHz) 


Center frequencies (MHz) 


14 MHz 


3407 


7 MHz 


3403.5 + 0.25 ne {0...28} 


3.5 MHz 


3401.75 + n • 0.25 ne{0...42} 


1.75 MHz 


3400.875 + n • 0.25 ne {0...49} 



8.3.11 Receiver requirements 
8.3.11.1 Receiver sensitivity 

The BER measured after FEC shall be less than 10" 6 at the power levels given by Equation (98) for standard 
message and test conditions. If the implemented bandwidth is not listed, then the values for the nearest 
smaller listed bandwidth shall apply. The minimum input levels are measured as follows: 

— At the antenna connector or through a calibrated radiated test environment, 

— Using the defined standardized message packet formats, and 

— Using an AWGN channel. 

The receiver minimum input level sensitivity (R ss ) shall be (assuming 5 dB implementation margin and 7 
dB Noise Figure): 

R ss = - 102 + SNR Rx + 10 • logf F s • ^ - (98) 

FFT 

where 

SNRfa the receiver SNR as per Table 266 in dB, 

F s sampling frequency in MHz as defined in 8.3.2.2, 

^subchannels me number of allocated subchannels (default 16 if no subchannelization is used). 



Table 266— Receiver SNR assumptions 



Modulation 


Coding rate 


Receiver SNR 
(dB) 


BPSK 


1/2 


6.4 


QPSK 


1/2 


9.4 


3/4 


11.2 
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Table 266— Receiver SNR assumptions (continued) 



Modulation 


Coding rate 


Receiver SNR 
(dB) 


16-QAM 


1/2 


16.4 


3/4 


18.2 


64-QAM 


2/3 


22.7 j 


3/4 


24.4 



Test messages for measuring Receiver Sensitivity shall be based on a continuous stream of MAC PDUs, 
each with a payload consisting of a R times repeated sequence S morfM ^/ 0 „. For each modulation, a different 
sequence applies: 

Sbpsk =[0xE4,0xB1] 

S qpsk = [0xE4, OxBl, OxEl, 0xB4] 

S 16-QAM = t 0xA8 > 0x20 ' 0xB9 > 0x3 !• 0xEC > 0x64 > 0xFD ' 0x75 l (99) 
S^. eAAf = [0xB6, 0x93, 0x49, 0xB2, 0x83, 0x08, 0x96, 0x11, 0x41, 0x92, 0x01, 0x00, 

OxBA, 0xA3, 0x8A, 0x9A, 0x21, 0x82, 0xD7, 0x15, 0x51, 0xD3, 0x05, 

0x10, OxDB, 0x25, 0x92, 0xF7, 0x97, 0x59, 0xF3, 0x87, 0x18, OxBE, 

0xB3, OxCB, 0x9E, 0x31, 0xC3, OxDF, 0x35, 0xD3, OxFB, 0xA7, 

0x9A, OxFF, 0xB7, OxDB] 

For each mandatory test message, the (R£ modulation ) tuples that shall apply are: 

Short length test message payload (288 data bytes): (144,%> 5A: ), (72,5 GP5A: ), (36 t S 16 Q AM ), 

Mid length test message payload (864 data bytes): (432,%> 5A: ), (2l6,S Q p SK ) t (10%,S 16 q AM \ 
(l$> S 64QAAf) 

Long length test message payload (1536 data bytes): (76%,S B p SK ), (384,5^^), 0-92,S i6 q AM ) 9 
@2,S 64 q AM ) 

The test condition requirements are: ambient room temperature, shielded room, conducted measurement at 
the RF port if available, radiated measurement in a calibrated test environment if the antenna is integrated, 
and RS FEC is enabled. The test shall be repeated for each test message length and for each (^,5 modutoiort ) 
tuple as identified above, using the mandatory FEC scheme. The results shall meet or exceed the sensitivity 
requirements set out in Equation (98). 

8.3.11.2 Receiver adjacent and alternate channel rejection 

The receiver adjacent and alternate channel rejection shall be met over the required dynamic range of the 
receiver, from 3 dB above the reference sensitivity level specified in 8.3.11.1 to the maximum input signal 
level as specified in 8.3.11.3. 

The adjacent channel rejection and alternate channel rejection shall be measured at minimum sensitivity by 
setting the desired signal's strength 3 dB above the rate dependent receiver sensitivity [see Equation (98)] 
and raising the power level of the interfering signal until the error rate specified in 8.3.11.1 is obtained. The 
adjacent channel rejection and alternate channel rejection shall also be measured at maximum input level by 
setting the interfering channel signal strength to the receiver maximum signal level as specified in 8.3.10.3 
and decreasing the power level of the desired signal until the specified error rate is obtained. In both cases, 
the power difference between the desired signal and the interfering channel is the corresponding C/T ratio. 
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The interfering signal shall be a conforming OFDM signal, unsynchronized with the signal in the channel 
under test. The requirement shall be met on both sides of the desired signal channel. For nonadjacent 
channel testing, the test method is identical except the interfering channel shall be any channel other than the 
adjacent channel or the co-channel. For the PHY to be compliant, the minimum rejection shall exceed the 
values shown in Table 267: 



Table 267— Adjacent and nonadjacent channel rejection 



Modulation/coding 


Adjacent Channel 
Interference C/I 
(dB) 


Nonadjacent 
channel rejection 
C/I (dB) 


16-QAM-3/4 


-11 


-30 


64-QAM-3/4 


-4 


-23 



8.3.11.3 Receiver maximum input signal 

The receiver shall be capable of decoding a maximum on-channel signal of -30 dBm. 

8.3.11.4 Receiver maximum tolerable signal 

The receiver shall tolerate a maximum signal of 0 dBm without damage. 

8.3.11.5 Receiver image rejection 

The receiver shall provide a minimum image rejection of 60 dB. The image rejection requirement shall be 
inclusive of all image terms originating at the receiver RF and subsequent intermediate frequencies. 

8.3.12 Frequency and timing requirements 

At the BS, the transmitted center frequency, receive center frequency and the symbol clock frequency shall 
be derived from the same reference oscillator. At the BS the reference frequency tolerance shall be better 
than ± 8*10~ 6 in licensed bands up to 10 years from the date of equipment manufacture. 

At the SS, both the transmitted center frequency and the symbol clock frequency shall be synchronized and 
locked to the BS with a tolerance of maximum 2% of the subcarrier spacing. 

For Mesh capable devices, all device frequencies shall be accurate to within ±20*10" 6 and achieve 
synchronization to its neighboring nodes with a tolerance of maximum 3% of the subcarrier spacing. 

During the synchronization period, the SS shall acquire frequency synchronization within the specified 
tolerance before attempting any uplink transmission. During normal operation, the SS shall track the 
frequency changes and shall defer any transmission if synchronization is lost. 

All SSs shall acquire and adjust their timing such that all uplink OFDM symbols arrive time coincident at 
the Base-Station to a accuracy of ±50% of the minimum guard-interval or better. 

8.4 WirelessMAN-OFDMA PHY 
8.4.1 Introduction 

The WirelessMAN-OFDMA PHY (Sari and Karam [B39]), based on OFDM modulation, is designed for 
NLOS operation in the frequency bands below 11 GHz per 1.3.4. For licensed bands, channel bandwidths 
allowed shall be limited to the regulatory provisioned bandwidth divided by any power of 2 no less than 
1.0 MHz. 
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8.4.2 OFDMA symbol description, symbol parameters and transmitted signal 
8.4.2.1 Time domain description 

Inverse-Fourier-transforming creates the OFDMA waveform; this time duration is referred to as the useful 
symbol time T b . A copy of the last T g of the useful symbol period, termed CP, is used to collect multipath, 
while maintaining the orthogonality of the tones. Figure 213 illustrates this structure. 




Figure 213— OFDMA symbol time structure 



The transmitter energy increases with the length of the guard time while the receiver energy remains the 
same (the cyclic extension is discarded), so there is a I0log(l - T/(T b + rp)/log(lO) dB loss in E^JNq. Using a 
cyclic extension, the samples required for performing the FFT at the receiver can be taken anywhere over 
the length of the extended symbol. This provides multipath immunity as well as a tolerance for symbol time 
synchronization errors. 

On initialization, an SS should search all possible values of CP until it finds the CP being used by the BS. 
The SS shall use the same CP on the uplink. Once a specific CP duration has been selected by the BS for 
operation on the downlink, it should not be changed. Changing the CP would force all the SSs to 
resynchronize to the BS. 

8.4.2.2 Frequency domain description 

The frequency domain description includes the basic structure of an OFDMA symbol. 

An OFDMA symbol is made up of subcarriers, the number of which determines the FFT size used. There are 
several subcarrier types: 

— Data subcarriers: for data transmission 

— Pilot subcarriers: for various estimation purposes 

— Null carrier: no transmission at all, for guard bands and DC carrier 

The purpose of the guard bands is to enable the signal to naturally decay and create the FFT "brick wall" 
shaping. 

In the OFDMA mode, the active subcarriers are divided into subsets of subcarriers, each subset is termed a 
subchannel. In the downlink, a subchannel may be intended for different (groups of) receivers; in the uplink, 
a transmitter may be assigned one or more subchannels, several transmitters may transmit simultaneously. . 
The subcarriers forming one subchannel may, but need not be adjacent. The concept is shown in Figure 214. 

The symbol is divided into logical subchannels to support scalability, multiple access, and advanced antenna 
array processing capabilities. 
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Figure 214— OFDMA frequency description (3 channel schematic example) 



8.4.2.3 Primitive parameters 

The following four primitive parameters characterize the OFDMA symbol: 

— BW: This is the nominal channel bandwidth. 

— Nused : Number of used subcarriers (which includes the DC subcarrier). 

— n: Sampling factor. This parameter, in conjunction with BW and Af used determines the subcarrier 
spacing, and the useful symbol time. This value is set to 8/7. 

— G: This is the ratio of CP time to "useful" time. The following values shall be supported: 1/32, 1/16, 
1/8, and 1/4. 

8.4.2.4 Derived parameters 

The following parameters are defined in terms of the primitive parameters of 8.4.2.3: 



— N FFT : Smallest power of two greater than N used 

— Sampling Frequency: F s = noor(n • w/8000) x 8000 

— Subcarrier spacing: A/ = FJ N FFT 

— Useful symbol time: T b = l/A/ 

— CP Time: T g = GT b 

— OFDMA Symbol Time: T s = T b +T g 

— Sampling time: T b /N FFT 



8.4.2.5 Transmitted signal 

Equation (100) specifies the transmitted signal voltage to the antenna, as a function of time, during any 
OFDMA symbol. 



Wused- l V 2 



j2nf c t 



s(t) = Re\ e ^ ■ e 

k*0 



j2KlcAf(t-T g ) 



(100) 



where 



t is the time, elapsed since the beginning of the subject OFDMA symbol, with 0 < t < T s . 
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c k is a complex number; the data to be transmitted on the subcarrier whose frequency offset index is k, 

during the subject OFDMA symbol. It specifies a point in a QAM constellation. 
Tg is the guard time. 

T s is the OFDMA symbol duration, including guard time. 
Af is the subcarrier frequency spacing. 

8.4.3 OFDMA basic terms definition 

8.4.3.1 Slot and Data Region 

A slot in the OFDMA PHY requires both a time and subchannel dimension for completeness (subchannels 
are defined in 8.4.6.) and is the minimum possible data allocation unit. 

The definition of an OFDMA slot depends on the OFDMA symbol structure, which varies for uplink and 
downlink, for FUSC and PUSC, and for the distributed subcarrier permutations and the adjacent subcarrier 
permutation. 

— For downlink FUSC using the distributed subcarrier permutation (defined in 8.4.6.1.2.2 and 
8.4.6.1.2.3), one slot is one subchannel by one OFDMA symbol. 

— For downlink PUSC using the distributed subcarrier permutation (defined in 8.4.6.1.2.1), one slot is 
one subchannel by two OFDMA symbols. 

— For uplink PUSC using either of the distributed subcarrier permutations (defined in 8.4.6.2.1 and 
8.4.6.2.5), one slot is one subchannel by three OFDMA symbols. 

— For uplink and downlink using the adjacent subcarrier permutation (defined in 8.4.6.3), one slot is 
one subchannel by one OFDMA symbol. 

In OFDMA, a Data Region is a two-dimensional allocation of a group of contiguous subchannels, in a group 
of contiguous OFDMA symbols. This allocation may be visualized as a rectangle, such as the 4 x 3 rectangle 
shown in Figure 215. 

Slot (Symbol Offset) 

Subchannel k - - • > > 

offset Y , . . | — 

A 

No_subchannels 

v illi 

fto_OFDM*symbols 

Figure 215— Example of the data region which defines the OFDMA allocation 

A data region can be transmitted in the downlink by the BS as a transmission to a (group of) SS(s). 

8.4.3.2 Segment 

A Segment is a subdivision of the set of available OFDMA subchannels (that may include all available sub- 
channels). One segment is used for deploying a single instance of the MAC. 

8.4.3.3 Permutation Zone 



496 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



lEEEStd 802.16-2004 



Permutation Zone is a number of contiguous OFDMA symbols, in the DL or the UL, that use the same 
permutation formula. The DL subframe or the UL subframe may contain more than one permutation zone. 

8.4.3.4 OFDMA data mapping 

MAC data shall be processed as described in 8.4.9 and shall be mapped to an OFDMA Data Region (see 
8.43.1) for downlink and uplink using the algorithms defined below. 

Downlink: 

1) Segment the data into blocks sized to fit into one OFDMA slot. 

2) Each slot shall span one or more subchannels in the subchannel axis and two OFDMA symbols 
in the time axis (see Figure 216). Map the slots such that the lowest numbered slot occupies the 
lowest numbered subchannel in the lowest numbered OFDMA symbol. 

3) Continue the mapping such that the OFDMA symbol index is increased. When the edge of the 
Data Region is reached, continue the mapping from the lowest numbered OFDMA symbol in 
the next subchannel. 

Uplink: 

1) Segment the data into blocks sized to fit into one OFDMA slot. 

2) Each slot shall span one or more subchannels in the subchannel axis and three OFDMA symbol 
. in the time axis (see Figure 217). Map the slots such that the lowest numbered slot occupies the 

lowest numbered subchannel in the lowest numbered OFDMA symbol. 

3) Continue the mapping such that the OFDMA symbol index is increased. When the edge of the 
UL zone (which is marked with Zone_switch_IE) is reached, continue the mapping from the 
lowest numbered OFDMA symbol in the next available subchannel. 

Figure 216 and Figure 217 illustrates the order in which OFDMA slots are mapped to subchannels and 
OFDMA symbols. 



Copyright © 2004 IEEE. All rights reserved. 



497 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



OFDMA Symbol Index 
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Figure 216— Example of mapping OFDMA slots to subchannels and symbols in the 

downlink (in PUSC mode) 



498 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



lEEEStd 802.16-2004 



Uplink Zone 



OFDMA Symbol Index 



k-2 k-\ 



k+l *+2 k+3 k+4 £+5 k+6 k+1 k+$ k+9 *+ll *+12 




Subchannel 
Index 

Figure 217— Example of mapping OFDMA slots to subchannels and symbols in the uplink 



8.4.4 Frame structure 

8.4.4.1 Duplexing modes 

In licensed bands, the duplexing method shall be either FDD or TDD. FDD SSs may be H-FDD. In license- 
exempt bands, the duplexing method shall be TDD. 

8.4.4.2 PMP frame structure 



When implementing a TDD system, the frame structure is built from BS and SS transmissions. Each frame 
in the downlink transmission begins with a preamble followed by a DL transmission period and an UL 
transmission period. In each frame, the TTG and RTG shall be inserted between the downlink and uplink 
and at the end of each frame, respectively, to allow the BS to turn around. 
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In TDD and H-FDD systems, subscriber station allowances must be made by a SSRTG and by a SSTTG 
The BS shall not transmit downlink information to a station later than (SSRTG+RTD) before its scheduled 
uplink allocation, and shall not transmit downlink information to it earlier than (SSTTG-RTD) after the end 
of scheduled uplink allocation, where RTD denotes Round-Trip Delay. The parameters SSRTG and SSTTG 
are capabilities provided by the SS to BS upon request during network entry (see 11.8.3.1). 
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Figure 218— Time plan - one TDD time frame (with only mandatory zone) 



Subchannel allocation in the downlink may be performed in the following ways: partial usage of 
subchannels (PUSC) where some of the subchannels are allocated to the transmitter, and full usage of the 
subchannels (FUSC) where all subchannels are allocated to the transmitter. The first two transmitted 
subchannels in the first data symbol of the downlink is called FCH. The FCH shall be transmitted using 
QPSK rate 1/2 with four repetitions using the mandatory coding scheme (e.g., the FCH information will be 
sent on four adjacent subchannels) in a PUSC zone. The FCH contains the DL_Frame Prefix as described in 
8.4.4.3, and specifies the length of the DL-MAP message that immediately follows the DL_Frame_Prefix 
and the repetition coding used for the DL-MAP message. 



The transitions between modulations and coding take place on OFDMA symbol boundaries in time domain 
and on subchannels within an OFDMA symbol in frequency domain. 

The OFDMA frame may include multiple zones (such as PUSC, FUSC, PUSC with all subchannels, 
optional FUSC, AMC and optional FUSC with all subchannels), the transition between zones is indicated in 
the DL-Map by the Zone_switch IE (see 8.4.5.3.4). No DL-MAP or UL-MAP allocations can span over 
multiple zones. Figure 219 depicts OFDMA frame with multiple zones. 
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Must appear in every frame 



May appear in a frame according to mapping 



Figure 21 9— Illustration of OFDMA frame with multiple zones 
8.4.4.3 DL Frame Prefix 

The DL_Frame_Prefix is a data structure transmitted at the beginning of each frame and contains 
information regarding the current frame and is mapped to the FCH. Table 268 defines the structure of 
DL_Frame_Prefix 



Table 268— OFDMA downlink Frame Prefix format 



Syntax 


Size 


Notes 


DL_Frame_Prefix_Format() { 






Used subchannel bitmap 


6 bits 


Bit #0: Subchannels 0-1 1 are used 
Bit #1: Subchannels 12-19 are used 
Bit #2: Subchannels 20-31 are used 
Bit #3: Subchannels 32-39 are used 
Bit #4: Subchannels 40-51 are used 
Bit #5: Subchannels 52-59 are used j 


Ranging_Change_Indication 


1 bit 




Repetition_Coding_Indication 


2 bits 


00 - No repetition coding on DL-MAP 

01 - Repetition coding of 2 used on 

DL-MAP 

10 - Repetition coding of 4 used on 

DL-MAP 

1 1 - Repetition coding of 6 used on 

DL-MAP 


Coding_Indication 


3 bits 


ObOOO - CC encoding used on DL-MAP 
ObOOl - BTC encoding used on DL-MAP 
ObOlO - CTC encoding used on DL-MAP 
ObOll - ZT CC used on DL-MAP 
OblOO to 0bl\\ -Reserved 
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Table 268— OFDMA downlink Frame Prefix format (continued) 



Syntax 


Size 


Notes 


DL-Map_Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


} 







Used subchannel bitmap 

A bitmap indicating which groups of subchannel are used on the PUSC zone. 
Ranging_Change_Indication 

A flag that indicates whether this frame contains a change of the allocation of Periodic Ranging/ 
BW Request uplink regions comparing to the previous frame. A value of "1" means that a change 
has occurred, and value of "0" means that the allocations of Periodic Ranging/B W Request regions 
in the current frame are the same as in the previous frame. 
Repetition_Coding_Indication 

Indicates the repetition code used for the DL-MAR Repetition code may be 0 (no additional repeti- 
tion), 1 (one additional repetition), 2 (three additional repetitions) or 3 (five additional repetitions). 
Codingjndication 

Indicates the FEC encoding code used for the DL-MAR The DL-MAP shall be transmitted with 
QPSK modulation at FEC rate 1/2. Note that the BS must ensure that DL-MAP (and other MAC 
messages required for SS operation) are sent with the mandatory coding scheme often enough to 
ensure uninterrupted operation of SS supporting only the mandatory coding scheme. 
DL-Map_Length 

Defines the length in slots of the DL-MAP message that follows immediately the 
DL_Frame_Prefix . 

Before being mapped to the FCH, the 24-bit DL Frame Prefix shall be duplicated to form a 48-bit block, 
which is the minimal FEC block size. 

8.4.4.4 Allocation of subchannels for FCH, and logical subchannel numbering 

In PUSC, any segment used shall be allocated at least 12 subchannels. The first 4 slots in the downlink part 
of the segment contain the FCH as defined in 8.4.4.2. These slots contain 48 bits modulated by QPSK with 
coding rate 1/2 and repetition coding of 4. The basic allocated subchannel sets for Segments 0, 1, and 2 are 
Subchannels 0-11, 20-31, and 40-51, respectively. Figure 220 depicts this structure. 
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Figure 220— FCH subchannel allocation for all 3 segments 



After decoding the DL_FrameJPrefix message within the FCH, the SS has the knowledge of how many and 
which subchannels are allocated to the PUSC segment. In order to observe the allocation of the subchannels 
in the downlink as a contiguous allocation block, the subchannels shall be renumbered. The renumbering 
shall start from the FCH subchannels (renumbered to values 0...11), then continue numbering the 
subchannels in a cyclic manner to the last allocated subchannel and from the first allocated subchannel to the 
FCH subchannels. Figure 221 gives an example of such renumbering for segment 1. For uplink, in order to 
observe the allocation of the subchannels as a contiguous allocation block, the subchannels shall be 
renumbered, the renumbering shall start from the lowest numbered allocated subchannel (renumbered to 
value 0), up to the highest numbered allocated subchannel, skipping non-allocated subchannels. Figure 222 
gives an example of such renumbering for segment 1. 
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Figure 221— Example of DL renumbering the allocated subchannels for segment 1 in PUSC 
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Figure 222— Example of UL renumbering the allocated subchannels for segment 1 in PUSC 

8.4.4.5 Uplink transmission allocations 

The allocation for a user uplink transmission is a number of subchannels over a number of OFDMA 
symbols. The number of symbols shall be equal to 3*N, where N is a positive integer. 

The basic allocation structure is one subchannel for a duration of 3 times the OFDMA symbol duration T s , 
(N = 1). Larger allocation are repetitions of the basic structure (N = k, for a positive integer k). 

The framing structure used for the uplink includes an allocation for ranging and an allocation for data 
transmission. The MAC layer sets the length of the uplink framing and the uplink mapping. 

8.4.4.6 Optional Diversity-Map Scan 
8.4.4.6.1 AAS frame structure 

The two highest numbered subchannels of the DL frame may be dedicated at the discretion of the BS for the 
AAS Diversity-Map Zone in PUSC, FUSC, and optional FUSC permutation. In the AMC permutation, the 
fourth and (N-4)th subchannels of the total N subchannels of the DL frame may be dedicated at the 
discretion of the BS for the AAS Diversity-Map Zone. For AMC permutation, each subchannel for the AAS 
diversity MAP consists of 3 bins by 2 symbols. When these subchannels are used for this purpose, they shall 
not be allocated in the normal DL-MAP message and shall be used only on the AAS portion of the DL 
subframe. These subchannels will be used to transmit the AAS-DLFP() whose physical construction is 
shown in Figure 223. 
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Figure 223— Example of allocation for AAS_DL_Scan IE 

The AAS portion in the DL (or UL) may be transmitted either by the FUSC/PUSC permutation or by the 
optional AMC permutation. Figure 224 shows an example of a DL subframe for each of these two possible 
variations. 
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Figure 224— AAS Diversity Map Frame Structure 



8.4.4.6.2 AAS-DLFP Format 

The purpose of the AAS-DLFP is to provide a robust transmission of the required base station parameters to 
enable SS initial ranging, as well as SS paging and access allocation. This is achieved through using a highly 
robust form of modulation and coding (namely QPSK-1/2 rate with 2 repetitions). The start of an AAS- 
DLFP is marked by an AAS DL preamble. The AAS-DLFPs transmitted within the AAS Diversity Map 
Zone need not carry the same information. Different beams may be used within the AAS Diversity Map 
Zone; however, each AAS Downlink Preamble and associated AAS-DLFP must be transmitted on the same 
beam. 

The AAS-DLFP supports the ability to transmit a MAP IE that carries a compressed DL-MAP. This 
allocation message can point to a broadcast DL-MAP that is beamformed or can be used to "page" a specific 
SS that cannot receive the normal DL-MAP. Once the initial allocations are provided to the user, private DL- 
MAPs and UL-MAPs can be sent on a beamformed transmission to the user at the highest modulation and 
lowest coding rate that can be supported by the link. The AAS-DLFP also has an uplink initial ranging 
allocation for AAS subscribers. 
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The contents of the AAS-DLFPQ payload is described by Table 269. 



Table 269— AAS-DLFP Structure, Diversity-Map Scan 



Syntax 


Size 


Notes 


AAS-DLFP() { 






AAS beam index 


6 bits 


This index is the index referred to by the 
AAS_Beam_Select message (see 6.3.2.3.41). 


Preamble select 


lbit 


0 - Frequency shifted Preamble 

1 - Time shifted Preamble 


Uplink_Preamble_Config 


2 bits 


00-0 symbols 
01 - 1 symbols 
10- 2 symbols 
1 1 - 3 symbols 


Downlink_Preamble_Config 


2 bits 


00- 0 symbols 

01- 1 symbols 

10- 2 symbols 

11- 3 symbols 


InitiaLRanging_Allocation_IE() { 






OFDM A Symbol Offset 


8 bits 




Subchannel offset 


6 bits 




No of OFDMA Symbols 


7 bits 




No of Subchannels 


6 bits 




Ranging Method 


2 bits 


00 - Initial Ranging over two symbols 

01 - Initial Ranging over four symbols 

10 - BW Request/Periodic Ranging over one 

symbol 

1 1 - B W Request/Periodic Ranging over three 

symbols 


} 






AAS_Comp_DL_IE() 


50 bits 




HCS 


8 bits 




} 
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Table 270— Structure of AAS_COMP_DLJE () 



Syntax 


Size 


Notes 


AAS_COMP_DLJE0 






CD) 


16 bits 




DIUC 


4 bits 


Set DIUC =15 to indicate the well known mod- 
ulation of OPSK encoded with the mandatory 

UlUllV/ll VI bllVK/UvU Willi Ulls llldllvldlVJl J 

CC at rate Vi \ 


OFDMA Symbol Offset 


8 bits 




Subchannel offset 


6 bits 




No of OFDMA Symbols 


7 bits 




No of Subchannels 


6 bits 




Boosting 


3 bits 




} 







8.4.4.6.3 AAS Downlink Preamble 

The AAS-DLFP is preceded by an AAS downlink preamble. In addition, the "Preamble Presence" field of 
the AAS_DLFP indicates the presence of an AAS downlink preamble on any downlink allocation made by 
the DLFR An AAS downlink preamble is formed by appropriately combining different preamble sequences 
defined in 8.4.6.1.1. An AAS allocation could be in the FUSC/PUSC/AMC allocation and therefore, 
depending on the type of allocation, a preamble may span more than one original preamble sequence defined 
in 8.4.6.1.1. In AMC allocation, the AAS downlink preamble occupies 9 subcarriers in each bin of the sub- 
channels in AAS operation. The AAS down link preamble number, K, \s derived from the AAS beam index 
carried by the AAS_DLFP(), and is limited to maximum 16 beams per segment (mainly in switching beams 
approach). When using the cyclic frequency shift preamble defined in 8.4.5.3.11, beams that use the same 
subchannels at the same time instance shall use a different AAS down link preamble number (K). 

8.4.4.6.4 AAS Uplink Preamble 

The "Preamble Presence" field of the AAS_DLFP indicates the presence of a preamble on any uplink 
bandwidth allocation made by the DLFP. The "Uplink_Preamble_Config" field indicates the size of the 
AAS uplink preamble. In the PUSC region, the AAS uplink preambles occupy 4 subcarriers and 1/2/3 
symbols. The basic AAS preamble (4 subcarrier x 1 symbol for PUSC or 9 subcarrier x 1 symbol for AMC 
or 3 subcarrier x 1 symbol for optional PUSC) is derived from the preambles defined in 8.4.6.1.1 similar to 
the downlink. In AMC allocation, the AAS uplink preamble occupies 9 subcarriers in each bin of the 
subchannels and 1, 2, or 3 symbols as specified in the. AAS-DLFP. 

8.4.4.7 Optional Direct Signaling Method 

The purpose of the AAS-DLFP2 using the direct signaling method is to provide a robust transmission of the 
basic base station parameters to enable AAS SS initial ranging and access requests. Once initial ranging is 
successful, the SS is provisioned with AAS signaling and training codes that provide the mechanism to 
adapt the antenna arrays at the base station (and SS). The SS can then receive compressed DL-Map and UL- 
Map messages from the base station with the required antenna array gain. Additionally, Method 2 provides 
multi-user beamforming in K spatial channels (where K < M antennas) that transport private access requests 
and private bandwidth allocations. 
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The AAS-DLFP2 message is sent in the BW allocation/access channel. This channel is constructed by using 
paired partitions in the frame. A partition is defined as a region that is 1 bin x J symbol slots where J is the 
number of symbol slots in a frame and an AMC bin is 9 adjacent subcarriers as defined in Figure 238. Only 
the transfer of basic base station parameters is conducted without beamforming using the most robust form 
of modulation and coding (namely QPSK-1/2 rate) together with redundant transmission that exploits 
spatial/spectral beam diversity. 

Method 2 supports the ability to transmit UL and DL MAPs simultaneously to multiple users on the BW 
allocation/access channel and to provide lower latency, direct AAS paging method described in the 
following text once these maps are received. The direct method provides the capability to start multiple data 
flows per frame in multiple regions of the frame over K spatial channels per region. 

8.4.4.7.1 Framing 

At least one BW allocation/access (BWAA) channel is allocated in the TDD AAS frame for network entry, 
ranging, bandwidth request, and AAS MAP communications. One BWAA channel is shown in Figure 225. 
Up to four of these channels may be provisioned as indicated in AAS-DLFP2. The location is identified in 
the UL-MAP as Initial-Ranging (UIUC=12), but shall be marked by an AAS initial ranging CID to ensure 
that no non- AAS subscribers use this region for initial ranging. The channel is formed using the first and last 
partition in the frame to improve channel reliability and SINR through beamforming and diversity 
combining methods. In the case that multiple BW allocation/access channels are specified, the first channel 
shall be constructed from the first partition and the partition indexed by P-(Nac-l) where P is the number of 
partitions and Nac is the number of BW allocation/access channels provisioned. AAS with FDHC 
(subclause 8.4.8.1.3) is used as the combining method on the BWAA channel. The channel is power boosted. 

At least one BW allocation/access channel is provisioned per RF channel. In addition, sectorized base 
stations provision at least one BWAA channel per sector. For the case where the RF band has been divided 
into sub-bands, at least one BWAA channel is provisioned per sub-band. 

The BW allocation/access channel is contention based. If collisions occur, SSs use the random back-off 
algorithm to randomize retry timing per 6.3.8. By using the signaling methods described below, an AAS 
base station is able to spatially separate K subscriber stations on the BWAA channel. This minimizes 
contention and linearly increases the number of logical BW allocation/access channels in proportion to the 
number of antennas used in the antenna array. 
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Frame Structure (20 MHz) 

Frame Duration 



BW Allocation & Access Channel 




Payload sub-chanriels 



UUDL MAP 

Figure 225— Frame Layout in the AAS Region 



The structure of the BW allocation/access channel is illustrated in Figure 226. In this figure, the two 
partitions forming the BW allocation/access channel are shown. This channel immediately follows the 
FUSC/PUSC DL and UL Map region in the downlink frame and is identified uniquely by the AAS AMC 
preamble. The channel shows a DLFP zone using fourth-order beam-pattern diversity and a payload region 
of six subchannels for the frame duration illustrated by this example. Two AAS control signals are also 
shown (FLI and FIT), which will be described the text below. Table 271 provides the AAS-DLFP2 data 
structure. This 6-byte data structure is repeated four times. It provides the necessary information for initial 
ranging and for reception of the initial ranging response messages to included the basic CID. This CID maps 
one-to-one into the Reverse Link Training (RLT) sequence index. The RLT is transmitted by the SS and is 
used to adapt the base station array. The data subchannels shown in Figure 226 support DL MAP and UL 
MAP messages. 
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Access/SICH Partition 



30 Symbols/Frame 




FLI FLT 

Diversity Zone, 4 DLFP2 3 Data Subchannels 
AAS Preamble (AAS DL-MAP) 



^ — 

1 BTC FEC Blocks every 1 Frames 



1 Frame 



Figure 226— Downlink BW Allocation/Access channel 



Table 271— AAS-DLFP2 Structure, Directed Signaling 



Syntax 


Size 


Notes 


AAS-DLFP2() { 






Frame_Number 


4 bits 


4 LSB of Frame Number field as specified 
in Table 273 


Base Station ID 


4 bits 


4 LSB 


Multiframe 


2 bits 


00 = 1 frame per multiframe 

01 = 2 frames per multiframe 

10 = 4 frames per multiframe 

1 1 = Reserved 


Uplink_Training_Config 

Downlink _Paging _Config 
AMC Subchannel Definition 


2 bits 


00-1x4 Training sequence 
01 - 2x2 Training sequence 
10 - 2x4 Training sequence 
11-1x8 Training sequence 
Ox - 1-FLI Paging sequence 
lx - 2-FLI Paging sequence 
xO - 1 bin x 6 slots subchannel 
xl - 2 bins x 3 slots subchannel 


Number of Access/DLFP Channels 


2 bits 


00 - 1 Channels 

01 -2 Channels 

10 - 3 Channels 

11- 4 Channels 


Initial Access Codes 


4 bits 
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Table 271— AAS-DLFP2 Structure, Directed Signaling (continued) 



Syntax 


Size 


Notes 


BS_EIRP+ EIRxP Irmax 


16 bits 




BW Allocation 


1 bit 


0 = UL/DL map only 

1 = UL/DL map w/ direct signaling 


HCS 


8 bits 




reserved 


5 bits 


Shall be set to zero 


} 







8.4.4.7.2 TDD Framing 

In the. informative text that follows, which describes this signaling, the example AAS system a frame 
duration of 5 ms and 48 OFDM A symbols per frame. The frame contains 192 bins x 48 symbols slots for the 
20 MHz RF channel described here. It is assumed for illustration purposes that 33 symbols are allocated to 
the forward link and 15 symbols are allocated to the reverse link resulting in 2 to 1 asymmetry (as 
determined by the base station) in the forward and reverse link rates. An AAS subchannel is defined as six 
consecutive bins in time (1 bin x 6 symbol slots). An alternate AAS subchannel, defined as a 2 bins x 3 
symbols cluster, is also supported as defined in the AAS-DLFP2. Mandatory CC coding and optional BTC 
or CTC FEC is supported by this frame structure. Figure 225 illustrates an AAS frame comprised of a 
forward and reverse link data area, the downlink preamble, map area, and dedicated BW allocation/access 
channel. 

8.4.4.7.3 Reverse link AAS control signals 

The reverse link partition in the TDD RL subframe is shown in Figure 227 for one of P (P = 192 for 
20 MHz) partitions. The reverse link in this example provides 15 symbol slots and is organized as two AAS 
subchannels. One of the 2 AAS subchannels contains one AAS reverse link control signal that is transmitted 
once every multiframe. A multiframe is 1, 2, or 4 frames. 

Two physical layer control signals are defined for the reverse link. The first is a reverse link training (RLT) 
signal, which allows an SS to send an AAS training signal to the base for a given subchannel. The RLT 
provides the time-bandwidth product necessary to adapt up to 12 antennas at the base station. The RLT 
signal shall occur at the beginning of the reverse link frame as shown in Figure 227 and is sent alternately 
every frame, every other frame, or every fourth frame as provisioned by the "multiframe parameter" in the 
AAS-DLFP2. MAC messages or traffic data are sent after the RLT in the first data subchannel and in 
subsequent subchannels thereafter also shown in Figure 227. The RLT occupies a maximum of eight symbol 
slots per partition providing 64 QPSK symbols for base station training. When used with fewer antennas, the 
RLT may be set to 32 QPSK symbols spanning 4 symbol slots to minimize training overhead. In addition, 
the RLT symbol sequence may span two adjacent bins. Accordingly, supported RLT cluster configurations 
are 1 x 8, 1 x 4, 2 x 4, and 2 x 2 (bins x symbol slots). 
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Reserved for Future U: 



i inns i 




RLI (8 Symbols) 
w/ Ranging 



Y 

1 Subchannel 



V 

2 Subchannels 



1 Frame 



1 BTC FEC Block or 3 RS-CC FEC Blocks per 2 Frames 

15 Symbols/Frame, 2 Frames Shown 



Figure 227— Reverse link AAS subframe structure showing RLT signaling 

The second control signal is the reverse link access (RLA) signal. The SS uses the RLA to train the base 
station antenna array on the BWAA channel. The RLA is sent ahead of the BW request message to inform 
the base that it has information to send on the uplink. The reverse link access partition is identical to the 
traffic partition shown in Figure 227 and the RLA sequence is identical to the RLT. The base in turn, with 
coordination through its scheduling mechanism, sets up traffic subchannels using map allocations followed 
by direct forward link control signaling as described below if enabled. 

8.4.4.7.4 Forward link AAS control signals 

The forward link partition is shown in Figure 228 for one of 192 partitions. The forward link partition in this 
example provides 33 symbol slots and is organized as five AAS subchannels. One of the five AAS 
subchannels contains three forward link control signals of two types applied once every multiframe. 

There are two types of AAS control signals used by the forward link. The first is the forward link initiation 
(FLI) signal. The FLI signals to the SS to initiate communications on traffic subchannels. This "paging" and 
"link initiation" signal is shown for the downlink frame structure shown in Figure 228 and has coding 
unique to an SS. One or two FLI signals are provisioned per AAS signaling subchannel in every multiframe 
frame. Each FLI signal modulates 16 tones (1 bin x 2 symbol slots) with 16 QPSK symbols. The FLI 
provides 12 dB (or 15 dB with soft combining) of processing gain to signal subscriber stations without 
directed beam steering knowledge. 
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aas Preamble First of 2 frames shown 




2 FLI (2 Symbols) 4 or 5 Subchannels 

1 FLT (2 Symbols) 

Use every other frame 



3 BTC FEC or 9 RS CC FEC Blocks every 2 Frames 



1 DL Sub- Frame 



Figure 228— Forward link subframe structure showing FLI and FLT signaling 

The forward link training (FLT) signal opportunity occupies the two bins located after the two FLI 
opportunities. The FLT transmits a known training sequence unique to the SS so that an SS can estimate and 
update the vector channel response. The FLT is sent in TDD systems with full beamforming gain. Multiple 
SSs may be trained on the same subchannel during the same time slot. 

8.4.4.7.5 Forward and reverse link bandwidth Request/Grant, Ranging 

If the RU is not yet ranged with the base station and hence, does not know the proper timing for reverse link 
transmissions, it randomly chooses an initial ranging access code, sends a RLA signal, detects a FLI 
response from the base, then adjusts its delay and transmit power based iteratively until an FLI is detected 
with maximum strength. This process is repeated until the best delay and transmit power have been 
identified. Once this has been accomplished, other periodic ranging mechanisms manage the transmit 
window time. The RU uses the RSS derived from forward link preamble measurements and the Base Station 
EIRP to set its initial transmit power level during initial ranging. 

8.4.4.7.6 PHY layer control signal sequencing 

The AAS physical layer is controlled via the signaling sequences described in this subclause. The following 
list provides a list of sequence actions keyed to the sequence diagram shown in Figure 229. For the first 
case, a base station initiated data flows subsequent to the receipt of the DL_MAP and ULJVIAP is 
considered. 

The base station uses the assigned SS access code to open subchannel(s) to an SS: 

1) Base station sends the FLI of the SS being addressed in the intended subchannel(s). 

2) SS looks for its assigned FLI in all subchannels. When it receives a FLI in a subchannel, it starts 

transmitting its RLT in the next reverse link time slot, followed by data in the subchannel. 

3) When base station receives the RLT, it performs the necessary training for both RL and FL 

directions. A beam is formed and the link is established. 

4) Base station transmits FLT in forward link time slot and user data in the subsequent subchannel. 
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'5) 



6) 



The (RLT + Data, FLT + Data) exchange continues as long as the subchannel is open. The 
absence of the FLT terminates the exchange. 
When the exchange stops, the SS stops transmitting RLT. 



The diagram on the left side of Figure 229 also illustrates the directed SS initiated connection. In this case, 
an RLA at step 0 is sent to the base station. The base station responds with a map allocation on the BWAA 
channel and FLIs and data in the appropriate data regions. The control sequence then is identical to the base 
initiated connection. 



SS 



BS 



SS 



BS 



RLA 





SS initiated 
connection 



BS initiated 
connection 



Figure 229 — PHY control signal sequence diagrams 



8.4.4.7.7 Granularity 

In the illustrated multiframe structure (see 8.4.4.7.3), an SS is allocated a continuous set of AAS 
subchannels spanning two frames (10 ms). The following table tabulates the granularity of bandwidth 
allocation in this scenario with forward and reverse link asymmetry parameter set to 50%. 
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Table 272— Bandwidth Granularity with AAS and AMC subchannels 



Modulation 
otnciut 


Bytes/ 

ciinpnQnnal 
S U UUldllll cl 


Bytes/10 ms (50% 

asj JllillcLJ y ) 


QPSK 1/2 


6 


36 


r\nc is ha 
Qrbiv 3/4 


y 


34 


16-QAM 1/2 


12 


72 


16-QAM 3/4 


18 


108 


64-QAM 1/2 


18 


108 


64-QAM 2/3 


24 


144 


64-QAM 3/4 


27 


162 



8.4.4.7.8 AMC Subchannel definition 

The AMC subchannel shall be defined as a region of 1 bin x 6 symbol slots or 2 bins x 3 symbol slots as 
configured in the AAS-DLFP2. The UL-MAP and DL-MAP IEs shall specify 192 (8 bits) bin locations in 
the frequency domain. 

8.4.4.7.9 PHY control signaling and coding structure 

The following subclauses describe the details of the AAS control signals. 

8.4.4.7.9.1 RLT and RLA code properties 

The properties of these signals are as follows: 

— Provides a spatial training sequence for up to 12 antennas with the appropriate time bandwidth 
product. 

— Provides unique SS identification at the base station. Both signals are detected with beamforming 
gain. 

— Provides a fine ranging structure within the symbol modulation. 

— 8064 codes are available based on 64 symbols. 

— High probability of detection, low false alarm rate consistent with modest cross-correlation 
properties between assigned codes at various code delays. 

— The same codes may be reused multiple times at the base station if sectors or sub-bands are used. 

— Robust code reuse factor of 4 between base stations. Further code de-correlation occurs for distance 
base stations due to base station to base station range differences. 

— The base station can separate multiple SS on the access subchannel using different RLAs. 

8.4.4.7.9.2 RLT and RLA code construction 

The RLT and RLA PHY control signals shall be based upon a compact 64 QPSK symbol message 
constructed from Hadamard sequences. The RLT and RLA shall be sent in the first symbol slots of the 
reverse link subframe. Each SS registered to a base is assigned a unique training and access code (RLT or 
RLA). The code index shall have a one-to-one mapping with the basic CID. The RLT and RLA code 
construction is identical. The RLT/RLAs shall be inserted into AAS partitions only at the start of the 
multiframe in the zeroth frame number of the zeroth partition and in the first frame of the first partition, etc. 
until the pattern repeats. The multiframe is defined in the AAS-DLFP2. 
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The access code may be reused from sub-band to sub-band or reused from sector to sector. Thus, within a 
given sub-band or sector, each SS has its own unique access code. There are a maximum of 8064 access 
codes. The access codes, a = 2016t + c, are divided into four equal sets; 0 < t < 4, where t is the base 
descriptor code. Each set of 2016 access codes is divided into three types with each type allocated a certain 
number of access codes: there are 2000 traffic access codes, c, for assigned SS: 0<c< 1999 , there are eight 
access codes, c, for SS initial registration: 2000 <c< 2007, and there are eight access codes, c, for SS initial 
ranging: 2008 <c< 2015. 

RLT and RLA codewords are based on Hadamard basis functions. RLTs and RLAs are described by an 
access index, a, 0 < a < 8064. A codeword, P lVo contains 64 QPSK symbols and has in-phase and 
quadrature components taken from the columns of a 64 by 64 Hadamard matrix, 



where, h z - and h f are different columns from the Hadamard matrix, A is an amplitude scaling factor and F x 
and F 2 are toggling matrices. The indices i 3 , i 2 , i h and i 0 select a particular RLT code. For a given access 
index, 

i, = mod (a, 64) ^ 
i 0 = mod (La/64 J + i x + 1, 64) 

For two given column indices, the access code is, 

a = 64 modO'o - i { + 64, 64) + i x ( 103 > 

8.4.4.7.9.3 FLI and FLT code properties 

The FLI and FLT control signals are based upon a compact 16 QPSK tones (8 tones/symbols, 2 symbols) 
message constructed from Kronecker products. The properties of these signals are as follows: 

— The FLT provides a vector channel training sequence for up to 4 degrees of freedom with the 
appropriate time bandwidth product. 

The FLT are multi-user directed transmissions and benefit from beamforming gain. 

— The FLT and FLI are uniquely coded and assigned to the SS by the base station. 

— 8064 codes are available based on 16 tones (8 tones/symbol, 2 symbols). 

— High probability of detection, low false alarm rate consistent with modest cross-correlation 
properties between assigned codes at various code delays. 

— The same codes may be reused multiple times at base station if sectors or sub-bands are used. 

— Robust code reuse factor of 4 between base stations. Code de-correlation occurs for distance base 
stations due to base station to base station range differences. 

— The FLI does identify which base is sending the FLI via recognition of the base descriptor code. 

8.4.4.7.9.4 FLI and FLT code construction 

Each SS registered with a base is assigned a unique link initiation and training code (FLI or FLT). Coding is 
the same for the FLI and FLT. There is a one-to-one mapping between the basic CID and FLI/FLT index. 
One or two FLI opportunities, as specified in the AAS-DLFP2, shall follow the AAS preamble in each 
partition. The FLT opportunity shall follow the last FLI. The FLI/FLTs shall be inserted into AAS partitions 
only at the start of the multiframe in the zero indexed frame number of the zero indexed partition and in the 




(101) 
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first indexed frame of the first indexed partition, etc. until the pattern repeats. The multiframe is defined in 
the AAS-DLFP2. 

The modulation on each tone of a FLI message is QPSK and thus can be represented by two bits of 
information. Each FLI message is described in a compact format by 32 bits: 16 tones by 2 bits per tone. A 
table can be used to represent these compact codewords. Annex B.5 lists 8064*2 FLI modulation codeword 
sequences, first codeword representing in-phase and second codeword representing quadrature-phase. Also, 
in each codeword, LSB represents lowest frequency tone and MSB represents highest frequency tone. 

8.4.4.7.9.5 AAS preamble 

The AAS preamble defines the AAS sub-region of the downlink subframe and shall be inserted as the first 
two symbol slots of the AAS partition as shown in Figure 226. The AAS preambles are based upon a 
compact 16 BPSK data symbol modulating the subcarriers in two adjacent AMC bins and is constructed by 
adaptively optimizing sequences based on the properties listed below: 

— The AAS preamble provides a preamble structure permitting SSs to rapidly acquire frequency, time, 
and frame, and multiframe synchronization with the base station 

— The AAS preamble shall be placed at the beginning of the AAS region 

— The AAS preamble codewords are selected so as to maximize the probability that the SS would lock 
onto the correct base, at the correct multiframe sequence, and the correct frequency. 

— The AAS preamble provides a preamble sequence with up to K,(4< K< 8) degrees of freedom to 
enhance SINR and reduce interference via adaptive combining. 

— The pattern of AAS preamble codewords is unique within a multiframe, and repeats from multiframe 
to multiframe. 

— The AAS preamble transmission uses a random space/frequency weight vector. Each AAS preamble 
coding cluster, defined as a 2 x 2 cluster of adjacent bins uses a different weight vector in the same 
time epoch. 

— 12 unique AAS preamble sequences indexed by base ID code are available. 

— Robust code reuse factor of 12 between base stations. 

8.4.4.7.9.6 AAS preamble construction 

The AAS preamble is a constant modulus BPSK code unique to a given base station defining the AAS 
region of the frame. The code uses nonlinear phase construction and is uncorrelated to the codes used by the 
other bases. Furthermore, the codeword in the second AAS preamble symbol slot does not resemble a 
complex scalar multiplying the codeword in the first AAS preamble symbol slot. The code is split into two 
codewords for the two AAS symbol slots in a forward link. Each length 16 codewords modulates the data 
subcarriers in two adjacent bins (a bin pair). 

The 32-element vector containing the code is multiplied by a pseudo random complex scalar for each of the 
K spread AAS preamble bin pairs. For each AAS preamble bin pair, the resulting 32 complex gain elements 
are split between the consecutive AAS symbol slots. The AAS preamble of the first symbol slot has the first 
16 complex elements and the AAS preamble of the second symbol slot has the second 16 complex elements. 
The base then transmits the code over the assigned AAS preamble bins pairs. 

An AAS base selects random transmit weight vectors for AAS preambles for each bin pair and spreading 
location. Each element of each transmit weight vector has the same amplitude and a randomly selected 
phase. The random number generator use at one base should not be correlated with or have the same repeat 
period as the generator of another bin pair of any base with a different base offset code. 

Every base uses a particular set of AAS codewords. The base offset code associated with the base forms part 
of the AAS codewords used by that base. AAS codeword sequences, like the base offset codes, may be 
reused every 12 cells. 
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8.4.5 Map message fields and lEs 

8.4.5.1 DL-MAP PHY Synchronization Field 

The format of the PHY Synchronization Field of the DL-MAP message, as described in 6.3.2.3.2 or 
Compressed_DL-MAP, as defined in 8.4.5.6, is given in Table 273. The Frame Duration Codes are given in 
Table 274. The Frame number is incremented by one each frame and eventually wraps around to zero. 



Table 273 — OFDMA PHY Synchronization Field 



Syntax 


Size 


Notes 


PHY_synchronization_field() { 






Frame duration code 


8 bits 




Frame number 


24 bits 




} 







A BS shall generate DL-MAP messages in the format shown in Table 16, including all of the following 
parameters: 

Frame number 

The frame number is incremented by 1 MOD 2 each frame. 
Frame Duration Code 

The frame duration Code values are specified in Table 274. 
8.4.5.2 Frame duration codes 

Table 274 defines the various frame durations that are allowed. The frame durations defined in the table 
indicate the periodicity of the downlink frame start preamble in both FDD and TDD cases. 



Table 274— OFDMA frame duration (7>ms) codes 



Code 

. (N) 


Frame duration 
(ms) 


Frames per second 


0 


N/A 


AAS-only gap up to 200 ms following (see 8.4.6.3) 


1 


2 


500 


2 


2.5 


400 


3 


4 


250 


4 


5 


200 


5 


8 


125 


6 


10 


100 


7 


12.5 


80 


8 


20 ms 


50 


9-255 


reserved 
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Note that the frame durations indicated in Table 274 typically are not integer multiples of one OFDMA sym- 
bol duration. Therefore some time padding may be necessary between the last useful OFDMA symbol of a 
frame and the beginning of the next frame. In addition, in the TDD case, note that the RTG and TTG guard 
intervals must be included in a frame. Both RTG and TTG shall be no less than 5 (is in duration. 

8.4.5.3 DL-MAP IE format 

The OFDMA DL-MAP IE defines a two-dimensional allocation pattern as defined in Table 275: 



Table 275— OFDMA DL-MAPJE format 



Syntax 


Size 


Notes 


DL-MAP_IE() { 






DIUC 


4 bits 




if (DRJC == 15) { 






Extended DIUC dependent IE 


variable 


See subclauses following 8.4.5.3.1 


} else { 






if (INC_CID ==1){ 




The DL-MAP starts with 
INC.CID =0. INC_CID is toggled 
between 0 and 1 by the 
CID-SWITCH_IE() (8.4.5.3.7) 


N_CID 


8 bits 


Number of CIDs assigned for this 
IE 


for (n=0; n< N_CID; n++) { 






CID 


16 bits 




} 






} 






OFDMA Symbol offset 


8 bits 




Subchannel offset 


6 bits 




Boosting 


3 bits 


000: normal (not boosted); 001: 
+6dB; 010: -6dB; 011: +9dB; 100: 
+3dB; 101: -3dB; 110: -9dB; 111: 
-12dB; 


No. OFDMA Symbols 


7 bits 




No. Subchannels 


6 bits 




Repetition Coding Indication 


2 bits 


ObOO - No repetition coding 
ObOl - Repetition coding of 2 used 
0b 10 - Repetition coding of 4 used 
0b 11- Repetition coding of 6 used 


} 






} 







Copyright ©2004 IEEE. All rights reserved. 



521 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS PART 16: 



DIUC 

DIUC used for the burst. 
Connection Identifier (CID) 

Represents the assignment of the IE to a broadcast, multicast, or unicast address. 
OFDMA Symbol offset 

The offset of the OFDMA symbol in which the burst starts, measured in OFDMA symbols trom 
beginning of the downlink frame in which the DL-MAP is transmitted. 
Subchannel offset 

The lowest index OFDMA subchannel used for carrying the burst, starting from subchannel U. 
Boosting 

Indication whether the subcarriers for this allocation are power boosted. 

No. OFDMA Symbols riDUV , . 

The number of OFDMA symbols that are used (fully or partially) to carry the downlink PHY Burst. 

No. of subchannels 

The number of subchannels with subsequent indexes, used to carry the burst. 
Repetition coding Indication 

Indicates the repetition code used inside the allocated burst. 
8.4.5.3.1 DIUC allocation 

Table 276 defines the DIUC encoding that should be used in the DL-MAP IEs. 



Table 276— OFDMA DIUC values 



DIUC 


Usage 


0-12 


Different burst profiles 


13 


Gap/PAPR reduction 


14 


End of map 


15 


Extended DIUC 1 



DIUC = 0 shall have burst profile parameters that are the same as those used for transmission of the DL-MAP 
message. 

DIUC = 13 may be used for allocation of Subchannels for PAPR reduction schemes. DIUC = 13 may also be 
used by the BS to create coverage enhancing safety zones. This is intended to provide reduced interference 
zones within the coverage area of the BS. The reduced interference zones are useful when the BS interfere 
with other BS. In such situations, the reduced interference zones may be used by the interfered BS to 
transmit data to SS that are registered with it, which would otherwise suffer from interference. 

8.4.5.3.2 DL-MAP extended IE format 

A DL-MAP IE entry with a DIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 277. A station shall ignore an extended IE entry with an extended DIUC 
value for which the station has no knowledge. In the case of a known extended DIUC value but with a length 
field longer than expected, the station shall process information up to the known length and ignore the 
remainder of the IE. 
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Table 277— DL-MAP extended IE format 



Syntax 


Size 


Notes 


DL__Extended_IE() { 






Extended DIUC 


4 bits 


0x00.. OxOF 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







8.4.5.3.3 AAS IE format 

Within a frame, the switch from non-AAS to AAS-enabled traffic is marked by using the extended DIUC = 
15 with the AAS_DL_IE() to indicate that the subsequent allocations, until the start of the first UL-MAP 
allocation using TDD, and until the end of the frame using FDD, shall be for AAS traffic. When used, the 
CID in the DL-MAP_IE() shall be set to the broadcast CID. All DL bursts in the AAS portion of the frame 
may be preceded by a preamble based on the indication in the AAS_DL_IE(). The preamble is defined in 
8.4.6.1.1, and shall be selected to have the same segment number as the DL frame preamble, and the cell ID 
shall equal to (DL-Preamble lDcell + 16) mod 32. The preamble shall exist only on those subchannels used 
by the DL burst. 



Table 278— OFDMA downlink AAS IE 



Syntax 


Size 


Notes 


AAS_DLJE() { 






Extended DIUC 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x03 


Permutation 


2 bits 


ObOO = PUSC permutation 

ObOl = FUSC permutation 

0b 10 = Optional FUSC permutation 

0b 11 = adjacent-subcarrier permutation 


Preamble indication 


2 bits 


ObOO = No preamble 
ObOl = Preamble used 
OblO-Obll = Reserved 


First bin index 


6 bits 


When Permutation=0bl0, this indicates the 
index of the first band allocated to this AMC 
segment ' 


Last bin index 


6 bits 


When Permutation=0bl0, this indicates the 
index of the last band allocated to this AMC 
segment 


} 
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8.4.5.3.4 Transmit diversity (TD)/Zone switch IE format 

In the DL-MAP, a BS may transmit DIUC=15 with the TD_ZONE_IE() to indicate that the subsequent 
allocations shall use a specific permutation, or be transmit diversity encoded. The downlink frame shall start 
in PUSC mode with IDcell = 0 and no transmit diversity. Allocations subsequent to this IE shall use the 
permutation and transmit diversity mode it instructs. 



Table 279 — OFDMA downlink TD_ZONE IE format 



Syntax 


Size 


Notes 


TD_ZONE_IE() { 






Extended DIUC 


4 bits 


TD/ZONE.S WITCH = 0x01 


Length 


4 bits 


Length = 0x02 


Permutation 


2 bits 


ObOU = PUoL permutation 

ObOl = FUSC permutation 

0b 10 = Optional FUSC permutation 

0b 11 = Adjacent subcarrier permutation 


Use All SC indicator 


1 bits 


0 = Do not use all subchannels 

1 Una oil pi»V\r»Vior4ti^»1 C 

1 — USe ail SUDdlallllCla 


Transmit Diversity 


2 bits 


ObOO = No transmit diversity 
ObOl = STC using 2 antennas 
OblO = STC using 4 antennas 
0b 11 = FHDC using 2 antennas 


Matrix Indicator 


2 bits 


Antenna STC/FHDC matrix (see 8.4.8) 
ObOO = Matrix A 
ObOl = Matrix B 

OblO = Matrix C (applicable to 4 antennas 

only) 
Obll = Reserved 


IDcell 


6 bits 




reserved 


2 bits 


Shall be set to zero 


} 







Permutation ... IC 

Indicates the permutation that shall be used by the transmitter for allocations following this IE. 
Permutation changes are only allowed on a zone boundary. The IDcell indicated by the IE shall be 
used as the basis of the permutation (see 8.4.6.1). 
Use All SC indicator 

When set, this indicator indicates transmission on all available subchannels. For hUi>C 
permutation, transmission is always on all subchannels. 
Transmit diversity 

Indicates the transmit diversity mode that shall be used by the transmitter for allocations following 
this IE (see 8 4.8). All allocations without transmit diversity shall be transmitted only from one 
antenna (antenna 0). The BS shall transmit from both its antennas for all allocations with transmit 
diversity. 
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8.4.5.3.5 Channel measurement IE 

An extended IE with an extended DIUC value of 0x00 is issued by the BS to request a channel measurement 
report (see 6.3.15). The IE includes an 8-bit Channel Nr value as shown in Table 280. 



Table 280— OFDMA channel measurement IE 



Syntax 


Size 


Notes 


Channel_Measurement_IE() { 






Extended DIUC 


4 bits 


CHM = 0x00 


Length 


4 bits 


Length = 0x04 


Channel Nr 


8 bits 


Channel number (see 8.5.1) 
Set to zero for licensed bands 


OFDMA symbol offset 


8 bits 




CID 


16 bits 


Basic CID of the SS for which the Channel 
measurement IE is directed 


} 







8.4.5.3.6 Data location in another BS IE 

In the DL-MAP, a BS may transmit DIUC=15 with the Data_location_in_another_BS_IE() to indicate that 
data is transmitted to the SS through another BS. This IE shall be sent right after the IE defining the same 
data received in the current BS. 



Table 281— OFDMA Data location in another BS IE 



Syntax 


Size 


Notes 


DataJocationjn_another_BS_IE() { 






Extended DIUC 


4 bits 


Data_location_in_another_BS = 0x3 


Length 


4 bits 


Length = OxOA 


reserved 


6 bits 


Shall be set to zero 


Segment 


2 bits 


Segment number 


Used subchannels 


6 bits 


Used subchannels at other BS 

Bit #0:0-11 1 

Bit #1: 12-19 

Bit #2: 20-31 

Bit #3: 32-39 

Bit #4: 40-51 

Bit #5: 52-59 


IDcell 


5 bits 


Cell ID of other BS 


Frame Advance 


3 bits 


The number of frames offset from the current 
frame where the data will be transmitted 
(0 = Next frame) 


OFDMA Symbol offset 


8 bits 
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Table 281— OFDMA Data location in another BS IE (continued) 



Syntax 


Size 


Notes 


Subchannel offset 


6 bits 




Boosting 


3 bits 


000: normal (not boosted); 001: +6dB; 010: 
-6dB; 011: +9dB; 100: +3dB; 101: -3dB; 

11W. "7UD, ill. - 1 Z^UU , 


No. OFDM Symbols 


8 bits 




No. Subchannels 


6 bits 




Repetition Coding Indication 


2 bits 


00 - No repetition coding 

01 - Repetition coding of 2 used 

10 - Repetition coding of 4 used 

1 1 - Repetition coding of 6 used 


} 







8.4.5.3.7 CID Switch IE 

In the DL-MAP, a BS may transmit DIUC=15 with the CD>Switch_IE() to toggle the inclusion of the CID 
parameter in DL-MAP allocations. The DL-MAP shall begin in the mode where CIDs are not included. The 
first appearance of the CID-Switch_IE() shall toggle the DL-MAP mode to include CIDs. Any subsequent 
appearance of the CID-Switch_IE() shall toggle the DL-MAP CID inclusion mode. 



Table 282— OFDMA downlink CID Switch IE format 



Syntax 


Size 


Notes 


CID-Switch_IE() { 






Extended DIUC 


4 bits 


CID-Switch = 0x04 


Length 


4 bits 


Length = 0x00 


} 







8.4.5.3.8 MIMO DL basic IE format 

In the DL-MAP, a MIMO-enabled BS may transmit DIUC = 15 with the MIMO_DL_Basic_IE() to indicate 
the MIMO configuration of the subsequent downlink allocation to a specific MIMO-enabled SS CID. The 
MIMO mode indicated in the MIMO_DL_Basic_IE() shall only apply to the subsequent downlink allocation 
until the end of frame. 
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Table 283— Ml MO DL basic IE format 



Syntax 


Size 


Notes 


MIMO_DL_BasicJE 0 { 






Extended DIUC 


4 bits 


MIMO = 0x05 


Length 


4 bits 


Length of the message in bytes (variable) 


Num_Region 


4 bits 




for ( i = 0; /< Num_Region; { 






OFDMA Symbol offset 


10 bits 




Subchannel offset 


5 bits 




Boosting 


3 bits 




No. OFDMA Symbols 


9 bits 




No. subchannels 


5 bits 




Matrix_indicator 


2 bits 


STC matrix (see 8.4.8.1.4.) 

Trans mit_diversity = transmit diversity mode 

indicated in the latest TD_Zone_IE(). 

if (Transmit J)iversity == 0b01) 

{ 

00 = Matrix A 

01 = Matrix B 

1 0 — 11 — Reserved 

} 

elseif (Transmit Diversity == 0b 10) 
{ 

00 = Matrix A 

01 = Matrix B 
10 = Matrix C 
11= Reserved 

i 


Numjayer 


2 bits 




for (j = 0; j< Numjayer; y++) { 






if(INC_CID == 1) { 






cn> 


16 bits 




} 






Layer_index 


2 bits 




DIUC 


4 bits 




} 






} 






} 







Num_Region 

This field indicates the number of the regions defined by OFDMA_Symbol_offset, 
SubchanneLoffset, Boosting, No._OFDMA_Symbols and No._subchannels in this IE. 
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Matrix_indicator 

The values of these two bits indicate the STC matrix (see 8.4.8.1.4). 
Numjayer 

The value of these 2 bits plus one indicate the number of MIMO transmission layers. 
Layerjndex 

This field specifies the layer index. 
8.4.5.3.9 MIMO DL Enhanced IE format 

In the DL-MAP, a MIMO-enabled BS may transmit DIUC = 15 with the MMO_DL_EnhancedJE() to 
indicate the MIMO mode of the subsequent downlink allocation to a specific MIMO-enabled SS identified 
by the CQICH.ID previously assigned to the SS. The MIMO mode indicated in the 
MIMO_DL_Enhanced_IE() shall only apply to the subsequent downlink allocation until the end of frame. 



Table 284— MIMO DL enhanced IE format 



Syntax 


Size 


Notes 


MIMO_DLJEnhanced_IE() { 






Extended DIUC 


4 bits 


EN_MIMO = 0x06 


Length 


4 bits 


Length of the message in bytes (variable) 


Num_Region 


4 bits 




for ( i = 0; i< Num_Region; i++) { 






OFDMA Symbol offset 


10 bits 




Subchannel offset 


5 bits 




Boosting 


1 hits 




No. OFDMA Symbols 


9 bits 




No. subchannels 


5 bits 




Matrix Jndicator 


2 bits 


STC matrix (see 8.4.8.1.4.) 
Transmit_diversity = transmit diversity mode 
indicated in the latest TD_Zone JE(). 
if (Transmit Diversity = ObOl) 
{ 

00 = Matrix A 

01 = Matrix B 
10- 11 = Reserved 

} 

elseif (Transmit J)iversity = OblO) 
{ 

00 = Matrix A 

01 = Matrix B 
10 = Matrix C 
11= Reserved 

} 


Numjayer 


2 bits 




for (j = 0;;< Numjayer; 7++) { 






if (INC_CID == 1) { 
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Table 284 — MIMO DL enhanced IE format (continued) 



Syntax 


Size 


Notes 


CQICID 


variable 


Index to uniquely identify the CQICH 
resource assigned to the SS. 
The size of this field is dependent on system 
parameter defined in DCD. 


) 






Layer_index 


2 bits 




DIUC 


4 bits 




} 






} 






} 







Num_Region 

This field indicates the number of the regions defined by OFDMA_Symbol_offset, 
SubchanneLoffset, Boosting, No._OFDMA_Symbols and No._subchannels in this IE. 
Matrix_indicator 

The values of these two bits indicate the STC matrix (see 8.4.8.1.4). 
CQICHJD 

This is the CQICH JD assigned to an SS in the CQICH_Alloc_IE(). The CQICH JD is used to 
uniquely identify an SS that is assigned a CQICH. 
Nurnjayer 

The value of these 2 bits plus one indicate the number of MIMO transmission layers. 
Layerjndex 

This field specifies the layer index. 
8.4.5.3.10 H-ARQ MAP Pointer IE 

This IE shall only be used by a BS supporting H-ARQ, for SS supporting H-ARQ. 



Table 285— H-ARQ MAP pointer IE format 



Syntax 


Size 


Notes 


MIMO_DL_Enhanced_IE() { 






Extended DIUC 


4 bits 


HARQ_P = 0x07 


Length 


4 bits 


Length = 0x02 


AMC DIUC 


4 bits 


Indicates the AMC level of the burst contain- 
ing a H-ARQ MAP message. 


No. Slots 


8 bits 


The number of slots allocated for the burst 
containing a H-ARQ MAP message. 


reserved 


4 bits • 


Shall be set to zero. 


} 
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AMC DIUC 

Indicates the burst profile used for the H-ARQ MAP message. 

No. Slots i # a t* tu 

The number of OFDMA slots allocated for the burst containing a H-ARQ MAP message. Ihe 
H-ARQ MAP message shall directly follows the DL MAP, the number of the slots allocated for 
the H-ARQ MAP message. 

8.4.5.3.11 DL-MAP Physical Modifier IE 

The Physical Modifier Information Element indicates that the subsequent allocations shall utilize a 
preamble, which is either cyclically delayed in time or cyclically rotated in frequency. 

In the case when the preamble is cyclically delayed in time by k samples, the preamble will contribute a 
component s(t) to the transmitted waveform as defined in Equation (104). 



S(t) = Re 



Wet 



k = N used /2 



2 C * Xg 



2jnk/N FFT 



k = -N used /2 



(104) 



where c k are the preamble tone values, and t is the time, elapsed since the beginning of the OFDMA symbol, 
with 0 < t < T s . The PHYMOD_DL_IE can appear anywhere in the DL map, and it shall remain in effect 
until another PHYMOD_DL_IE is encountered, or until the end of the DL map. 

In the case when the preamble is cyclically shifted in frequency, the preamble subcarriers will be shifted 
such that: 



C*ew.K = ( C Origi n al + 5 - K ) mod N Used- Subcarriers 



(105) 



Where C NeWfK is the new subcarrier index and C 0riginal is the original subcarrier index, and K is the 
frequency shift index indicated in the PHYMOD_DL_IE. 



Table 286— OFDMA DL-MAP Physical Modifier IE format 



Syntax 


Size 


Notes 


PHYMODJDL_IE() { 






Extended DIUC 


4 bits 


PHYMOD = 0x08 


Length 


4 bits 


Length = 0x03 


Preamble Modifier Type 


lbit 


0 - Randomized preamble 

1 - Cyclically shifted Preamble 


if (Preamble Modifier Type == 0) { 






Preamble frequency shift index 


4 bits 


Indicates the value of K in Equation (105) 


} else { 






Time index shift type 


lbit 


0 - Rounded down shift 

1 - Exact shift 


if (Time index shift type ==0) { 
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Table 286— OFDMA DL-MAP Physical Modifier IE format (continued) 



Syntax 


Size 


Notes 


Preamble Time Shift Index 


4 bits 


For PUSC, 

0-0 sample cyclic shift ! 
1 - floor(N/r/r7/14) sample cyclic shift 

i j — iiijviyiv Fpji ih ij) sample cycnc sniii 
14-15 - reserved 

For AMC permutation, 

0-0 sample cyclic shift 

1 - f\oor(N FFI J9) sample cyclic shift 

8 - f\oor(N FFT /9*&) sample cyclic shift 
9-15 -reserved 


} else { 






Preamble Time Shift Index 


4 bits 


For PUSC, 

0-0 sample cyclic shift 

1 - floor(N ffjJ\$) sample cyclic shift 

id — iiooi\iv fpyi I** id) sample cyclic snirt 
14-15 - reserved 

For AMC permutation, 

0-0 sample cyclic shift 

1 - f\ooT(N FF7 J9) sample cyclic shift 

8 - f\oor(N FF7 J9*&) sample cyclic shift 
9-15 - reserved 


} 






} 






reserved 


2 bits 


Shall be set to zero 


} 







Preamble Modifier type 

This parameter defines whether the preamble will be cyclically shifted in time or in frequency. 
Preamble frequency shift index 

This parameter effects the cyclic shift of the preamble in frequency axis, as defined by 
Equation (105). 

Preamble Time Shift Index 

This parameter defines how many samples of cyclic shift shall be introduced into the preamble 
symbols. The unit of cyclic shift depends on the subchannel permutation to ensure the frequency- 
domain orthogonality between the different preambles in the same subchannel. 

8.4.5.4 UL-MAP IE format 

The OFDMA UL-MAP IE defines uplink bandwidth allocations. If OFDMA UL-MAP IE with UIUC = 12 
or UIUC = 13 exists, they must be always allocated first. The first OFDMA UL-MAP IE, with UIUC other 
than 12 or 13, shall start at the lowest numbered non-allocated subchannel on the first non-allocated 
OFDMA symbol defined by the allocation start time field of the UL-MAP message that is not allocated with 
UIUC = 12 or UIUC = 13 (See Figure 217 for an example). These IEs shall represent the number of slots 
provided for the allocation. Each allocation IE shall start immediately following the previous allocation and 
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shall advance in the time domain. If the end of the UL frame has been reached, the allocation shall continue 
at the next subchannel at first OFDMA symbol (define by the allocation start time field) that is not allocated 
with UIUC = 12 or UIUC = 13. The CID represents the assignment of the IE to either a unicast, multicast, or 
broadcast address. A UIUC shall be used to define the type of uplink access and the burst type associated 
with that access. A Burst Descriptor shall be specified in the UCD for each UIUC to be used in the UL-MAP. 
The format of the UL-MAP IE is defined in Table 287. 



Table 287— OFDMA UL-MAP IE format 



Syntax 


Size 


Notes 


UL-MAPJEO { 






CID 


1 (L kite 




UIUC 


4 bits 




if (UIUC = 12) { 






OFDMA Symbol offset 


Q kite 

o DltS 




Subchannel offset 


/ DltS 


. 


No. OFDMA Symbols 


/bits 




No. Subchannels 


/ bits 




Ranging Method 


O Kite 

z bits 


(\V\f\f\ Initial Pnnm'na nvpr two <;vmhols 
UDUU — lillllal Ixallglllg uvci iwu ay uiuimb 

0b01 - Initial Ranging over four symbols 
OblO - BW Request/Periodic Ranging over one 
symbol 

Obll - BW Request/Periodic Ranging over three 
symbols 


reserved 


1 bit 


Shall be set to zero 


}else if (UIUC == 14) { 






CJJiVlA_AUocauon_itLiU 


32 bits 




else if (UIUC == 15) { 






Extended UIUC dependent IE 


variable 


See subclauses following 8.4.5.4.3 


} else { 






Duration 


10 bits 


In OFDMA slots (see 8.4.3.1) 


Repetition coding indication 


2 bits 


ObOO - No repetition coding 
ObOl - Repetition coding of 2 used 
0b 10 - Repetition coding of 4 used 
Obll - Repetition coding of 6 used 


} 






Padding nibble, if needed 


4 bits 


Completing to nearest byte, shall be set to 0. 


} 







CID 

Represents the assignment of the IE. 
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UIUC 

UIUC used for the burst. 
OFDMA Symbol offset 

The offset of the OFDMA symbol in which the burst starts, the offset value is defined in units of 
OFDMA symbols and is relevant to the Allocation Start Time field given in the UL-MAP message. 
Subchannel offset 

The lowest index subchannel used for carrying the burst, starting from subchannel 0. When 
allocation of mini-subchannels is used, this offset will always be even numbered and will point to 
the first subchannel of the couple splitted into mini-subchannels and used in the allocation. 
No. OFDMA Symbols 

The number of OFDMA symbols that are used to carry the uplink Burst. 
No. subchannels 

The number of subchannels with subsequent indices. 
Duration 

Indicates the duration, in units of OFDMA slots, of the allocation. 
Repetition coding indication 

Indicates the repetition code used inside the allocated burst. 
8.4.5.4.1 UIUC Allocation 

Table 288 defines the UIUC encoding that should be used in the UL-MAP_IE(). 



Table 288— OFDMA UIUC values 



UIUC 


Usage 


0 


FAST-FEEDBACK Channel 


1-10 


Different burst profiles 


11 


End of Map IE 


12 


CDMA Bandwidth Request, 
CDMA ranging 


13 


PAPR reduction allocation, 
Safety zone 


14 


CDMA Allocation IE 


15 


Extended UIUC 



The UIUC = 13 is used for allocation of Subchannels for PAPR reduction schemes. These tones may be used 
by all SSs to reduce PAPR of their transmissions. Alternatively, it can also be used by the BS to create 
coverage enhancing safety zones for uplink. This is intended to provide reduced interference zones within 
the coverage area of the SS. The reduced interference zones are useful when the SS in the neighboring BS 
are near the cell edge and interfering with SS in the current BS. In such situations, the reduced interference 
zones may be used by the SS in the neighboring BS so that the SS in the current BS do not suffer from 
interference. 

NOTE— The CDMA allocation UIUC provides (among other things) a function similar to the initial ranging UIUC used 
in other PHY options; therefore, instructions that relate to messages transmitted in the initial ranging UIUC shall apply 
to messages transmitted in the CDMA allocation UIUC as well. 
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8.4.5.4.2 PAPR reduction/Safety zone allocation IE 

Table 289 defines the PAPR reduction allocation and safety zone allocation IE. This IE is identified by 
UIUC = 13. 



Table 289— PAPR reduction and safety zone allocation IE format 



Syntax 


Size 


Notes 


PAPR Reduction_and_Safty_Zone_Allocati 
on JEO { 






OFDMA symbol offset 


8 bits 




Subchannel offset 


7 bits 




No. OFDMA symbols 


7 bits 




No. subchannels 


7 bits 




PAPR Reduction/Safety Zone 


1 bit 


0 = PAPR reduction allocation 

1 = Safety zone allocation 


reserved 


2 bits 


Shall be set to zero 


} 







OFDMA Symbol offset 

The offset of the OFDMA symbol in which the burst starts, the offset value is defined in units of 
OFDMA symbols and is relevant to the Allocation Start Time field given in the UL-MAP message. 
Subchannel offset 

The lowest index subchannel used for carrying the burst, starting from subchannel 0. 
No. OFDMA Symbols. 

The number of OFDMA symbols that are used to carry the uplink Burst. 
Number of subchannels 

The number subchannels with subsequent indexes, used to carry the burst. 
8.4.5.4.3 CDMA allocation UL-MAP IE format 

Table 290 defines the UL-MAP_IE for allocation of bandwidth to a user that requested bandwidth using a 
CDMA request code. This IE is identified by UIUC =14. 



Table 290— CDMA Allocation IE format 



Syntax 


Size 


Notes 


CDMA_Allocation_IE() { 






Duration 


6 bits 




Repetition Coding Indication 


2 bits 


ObOO - No repetition coding 
ObOl - Repetition coding of 2 used 
0b 10 - Repetition coding of 4 used 
0b 11 - Repetition coding of 6 used 


Ranging Code 


8 bits 
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Table 290— CDMA Allocation IE format (continued) 



Syntax 


Size 


Notes 


Ranging Symbol 


8 bits 




Ranging subchannel 


7 bits 




BW request mandatory 


1 bit 


1= yes, 0= no 


} 







Duration 

Indicates the duration, in units of OFDMA slots, of the allocation. 
Repetition coding indication 

Indicates the repetition code used inside the allocated burst. 
Ranging Code 

Indicates the CDMA Code sent by the SS. 
Ranging Symbol 

Indicates the OFDMA symbol used by the SS. 
Ranging subchannel 

Identifies the Ranging subchannel used by the SS to send the CDMA code. 
BW request mandatory 

Indicates whether the SS shall include a Bandwidth (BW) Request in the allocation. 
8.4.5.4.4 UL-MAP extended IE format 

A UL-MAP IE entry with a UIUC value of 15, indicates that the IE carries special information and conforms 
to the structure shown in Table 291. A station shall ignore an extended IE entry with an extended UIUC 
value for which the station has no knowledge. In the case of a known extended UIUC value but with a length 
field longer than expected, the station shall process information up to the known length and ignore the 
remainder of the IE. 



Table 291— OFDMA UL-MAP extended IE format 



Syntax 


Size 


Notes 


UL_Extended_IE() { 






Extended UIUC 


4 bits 


OxOO..0x0F 


Length 


4 bits 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







8.4.5.4.5 Power Control IE format 

When a power change for the SS is needed, the extended UIUC = 15 may be used with the subcode 0x00 and 
with 8-bit power control value as shown in Table 292. The power control value is an 8-bit signed integer 
expressing the change in power level (in 0.25 dB units) that the SS should apply to correct its current 
transmission power. 
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The CID used in the IE should be the Basic CID of the SS. 

Table 292— OFDMA Power Control IE 



Syntax 


aize 


Notes 


Power_ControLIE() { 






Extended UIUC 


4 bits 


Fast power control = 0x00 


Length 


4 bits 


Length = 0x01 


Power control 


8 bits 


Signed integer, which expresses the' change in 
power level (in 0.25 dB units) that the SS should 
apply to correct its current transmission power. 


} 







8.4.5.4.6 AAS IE format 

Within a frame, the switch from non-AAS to AAS-enabled traffic is marked by using the extended 
UIUC = 15 with the AAS_UL_IE() to indicate that the subsequent allocation until the end of the frame shall 
be for AAS traffic. When used, the CID in the UL-MAP_IE() shall be set to the broadcast CID. All UL 
bursts in the AAS portion of the frame may be preceded by a preamble based on the indication in the 
AAS_UL_IE(). The preamble is defined in 8.4.9.4.3.1 

Table 293— OFDMA uplink AAS IE 



Syntax 


Size 


Notes 


AAS_UL_IE() { 






Extended UIUC 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x03 


Permutation 


2 bits 


ObOO = PUSC permutation 
ObOl = Optional PUSC permutation 
0b 10 = adjacent- subcarrier permutation 
0b 11 = Reserved 


OFDMA symbol offset 


8 bits 




Preamble indication 


2 bits 


ObOO = No preamble 
ObOl = Preamble used 
OblO-Obll = Reserved 


First bin index 


6 bits 


When Permutation = 0b 10, this indicates the 
index of the first band allocated to this AMC 
segment 


Last bin index 


6 bits 


When Permutation = OblO, this indicates the 
index of the last band allocated to this AMC 
segment 


} 
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8.4.5.4.7 UL Zone switch IE format 

In the UL-MAP, a BS may transmit UIUC = 15 with the ZONE_IE() to indicate that the subsequent 
allocations shall use a specific permutation. The uplink frame shall start in PUSC mode with ULJDcell as 
indicated in the UCD message. Allocations subsequent to this IE shall use the permutation it instructs. 



Table 294— OFDMA uplink ZONE IE format 



Syntax 


Size 


Notes 


ZONEJE0 { 






Extended DIUC 


4 bits 


ZONE = 0x04 


Length 


4 bits 


Length = 0x03 


OFDMA symbol offset 


7 bits 




Permutation 


2 bits 


ObOO = PUSC permutation 

ObOl = PUSC permutation 

0b 10 = Optional PUSC permutation 

0b 11 = Adjacent subcarrier permutation 


PUSC ULJDcell 


7 bits 




} 







OFDMA symbol offset 

The offset of the OFDMA symbol in which the zone starts, the offset value is defined in units of 
OFDMA symbols and is relevant to the Allocation Start Time field given in the UL-MAP message. 
Permutation 

Indicates the permutation that shall be used by the transmitter for allocations following this IE. 
Permutation changes are only allowed on a zone boundary. The ULJDcell indicated by the IE shall 
be used as the basis of the permutation (see 8.4.6.2.2, 8.4.6.2.3). 

8.4.5.4.8 Mini-subchannel allocation IE 

The mini-subchannel allocation IE is used for subdividing subchannels into mini-subchannels. This IE 
uses the extended UIUC = 15 with the subcode 0x01 with the structure shown in Table 295. The CID in 
the UL-MAP when using the mini-subchannel allocation IE shall be set to the broadcast CID. 



Table 295— Mini-subchannel allocation IE format 



Syntax 


Size 


Notes 


Mini_subchannel_allocation_IE() { 






Extended DIUC 


4 bits 


Mini_subchannel_allocation = 0x01 


Length 


4 bits 


Length(M) = 0x03 if M=2 
0x04 if A/=3 
0x06 if Af=6 


CType 


2 bits 


ObOO - 2 mini -subchannels (defines M=2) 
ObOl - 2 mini-subchannels (defines M=2) 
OblO - 3 mini-subchannels (defines A/=3) 
0b 11 - 6 mini-subchannels (defines A/=6) 
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Table 295— Mini-subchannel allocation IE format (continued) 



Syntax 


Size 


Notes 


Duration 


10 bits 


In OFDMA slots 1 


For(/=0;y<M;;++){ 






CIDtf) 


16 bits 




UIUC(/) 


4 bits 


Allowed values are 1-10 


Repetition^") 


2 bits 


Indicates the repetition code used inside the 
allocated burst for minisubchannel with 
index j 

ObOO - No repetition coding 
ObOl - Repetition coding of 2 used 
0b 10 - Repetition coding of 4 used 
0b 11 - Repetition coding of 6 used 


} 






Padding 


n bits 


Padding bits shall be set to zero 
rt = 0ifM=2 

2ifM=3 

0ifM=6 


} 







Ctype 

Defines Af, the number of mini- subchannels allocated by this IE. 
Duration 

Defines the allocation duration in OFDMA slots. The duration shall be an integer multiple of M. 
CID(/) 

CID to use for mini- subchannel with index j. 
UlUCtf) 

UIUC to use for mini-subchannel with index j. Allowed values are 1-10. 
Repetition^*) 

Indicates the repetition code used inside the allocated burst for mini- subchannel with index). 
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8.4.5.4.9 FAST-FEEDBACK message mapping 



Each FAST-FEEDBACK message occupies one UL slot. FAST-FEEDBACK messages are mapped in to the 
region marked by UIUC=0 in the UL-MAP, in a time-first order, as shown in Figure 230. 
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(size = 3 OFDI 



















































Figure 230— Mapping order of FAST-FEEDBACK messages to the FAST-FEEDBACK region 



8.4.5.4.10 FAST_FEEDBACK channels 

Fast feedback slots may be individually allocated to SS for transmission of PHY related information that 
requires fast response from the SS. The allocations are done in unicast manner through the 
FAST_FEEDBACK MAC subheader (see 6.3.2.2.6), and the transmission takes place in a specific UL 
region designated by UIUC = 0. 

Each Fast-feedback slot consists of 1 OFDMA slots mapped in a manner similar to the mapping of normal 
uplink data. A fast feedback slot uses QPSK modulation on the 48 data subcarriers it contains, and can carry 
a data payload of 4 bits. Table 296 defines the mapping between the payload bit sequences and the 
subcarriers modulation. 



Table 296 — FAST_FEEDBACK channel subcarrier modulation 



4 bit payload 


Fast Feedback vector indices per Tile 
Tile(0),Tile(l),...,THe(5) 


ObOOOO 


0,0,0,0,0,0 


ObOOOl 


1,1,1,1,1,1 


ObOOlO 


2,2,2,2,2,2 


ObOOll 


3,3,3,3,3,3 
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Table 296— FAST_FEEDBACK channel subcarrier modulation (continued) 



- 4 bit payload 


Fast Feedback vector indices per Tile 


Tile(O), Tile(l), ... ,Tile(5) 


ObOlOO 


4,4,4,4,4,4 


ObOlOl 


5,5,5,5,5,5 


ObOllO 


6,6,6,6,6,6 


ObOlll 


7,7,7,7,7,7 


OblOOO 


0,1,2,3,4,5 


OblOOl 


1,2,3,4,5,6 


OblOlO 


2,3,4,5,6,7 


Ob 1011 


3,4,5,6,7,0 


Ob 1100 


4,5,6,7,0,1 J 


ObllOl 


5,6,7,0,1,2 


OblllO 


6,7,0,1,2,3 


! Obllll 


7,0,1,2,3,4 1 



The fast-feedback code words used in Table 296 belong to a set of orthogonal vectors and are mapped 
directly to the subcarriers (see 8.4.9.4.2), where subcarriers(O) is the lowest numbered data subcarrier in the 
tile, and the tile indices are defined by the permutation (see 8.4.6.2). The vectors are defined in Table 297. 

Table 297— FAST_FEEDBACK subcarrier modulation in each vector 



Vector index 


Data subcarrier modulation per Code word 
Subcarrier(O), Subcarrier(l), ... Subcarrier(7) 


0 


P0,P1,P2,P3,P0,P1,P2,P3 


S 1 


P0,P3,P2,P1,P0,P3,P2,P1 


2 


P0,P0,P1,P1,P2,P2,P3,P3 


3 


P0,P0,P3,P3,P2,P2,P1,P1 


4 


P0,P0,P0,P0,P0,P0,P0,P0 


5 


P0,P2,P0,P2,P0,P2,P0,P2 


6 


P0,P2,P0,P2,P2,P0,P2,P0 


7 


PO,P2,P2,P0,P2,P0,P0,P2 



Where, 
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(106) 



The fast feedback slot includes 4 bits of payload data, whose encoding depended on the instruction given in 
the FAST_FEEDBACK subheader. The following subclauses define these encodings. 

8.4.5.4.10.1 Fast DL measurement feedback 

When the FAST_FEEDBACK subheader Feedback Type field is "00" the SS shall report the S/N it 
measures on the DL. Equation (107) shall be used: 



Payload bits nibble = 



0 S/N<-2dB 

n 2-n-4<S/N<2-n-2 

15 S/N>26dB 



0<n<15 



(107) 



8.4.5.4.10.2 Fast MIMO feedback 



When the FAST_FEEDBACK subheader Feedback Type field is "01" or "10" the SS shall report the MIMO 
coefficient the BS should use for best DL reception (see 8.4.8.1.6). The mapping for the complex weights is 
shown in Figure 231. 
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Figure 231— Mapping of MIMO coefficients to fast MIMO feedback payload bits 



8.4.5.4.10.3 Mode Selection Feedback 

When the FAST-FEEDBACK subheader Feedback Type field is "11" or at a specific frame indicated in the 
CQICH_AllocJE(), the SS shall send its selection in terms of MIMO mode (STTD versus SM) or 
permutation mode on the assigned FAST-FEEDBACK channel. Table 298 shows the encoding of payload 
bits for the FAST-FEEDBACK slot (see 8.4.5.4.9). 



Table 298— Encoding of payload bits for FAST-FEEDBACK slot 



Value 


Description 


ObOOOO 


STTD and PUSC/FUSC permutation 


ObOOOl 


STTD and adjacent-subcarrier permutation 


ObOOlO 


SM and PUSC/FUSC permutation 


ObOOll 


SM and adjacent-subcarrier permutation 


ObOlOO 


reserved 
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8.4.5.4.11 MIMO UL Basic IE format 

In the.UL-MAP, a MIMO-enabled BS may transmit UIUC = 15 with the MIMO_UL_Basic_IE() to indicate 
the MIMO mode of the subsequent uplink allocation to a specific MIMO-enabled SS CID. The MIMO mode 
indicated in the MIMO JJL_Basic_IE() shall only apply to the subsequent uplink allocation until the end of 
frame (see Table 299). 



Table 299— MIMO UL basic IE format 



Syntax 


Size 


Notes 


MIMO_UL_Basic_IE () { 






Extended DIUC 


4 bits 


MIMO = 0x02 


Length 


4 bits 


Length of the mes^app in hvtp<; (variahlp^ 


Num_Assign 


4 bits 


Number of burst assignment 


For (/=0; ./<Num_assign; { 






CID 


16 bits 


SS basic CID 


UIUC 


4 bits 




MIMO_Control 


lbit 


For dual transmission capable SS 
0: STTD 
1:SM 

For Collaborative SM capable SS 
0: pilot pattern A i 
1: pilot pattern B 


Duration 


10 bits 


In OFDMA slots (see 8.4.3.1) 


} 






} 







Num_assign 

This field specifies the number of assignments in this IE. 
MIMO_ControI 

MIMO_Control field specifies the MIMO mode of UL burst. For a dual transmission-capable SS, the 
value of 0 indicates STTD mode, the value of 1 indicates SM mode. For a collaborative SM- capable 
SS, the value of 0 indicates pilot pattern A, the value of 1 indicates pilot pattern B. 
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8.4.5.4.12 CQICH Allocation IE Format 

CQICH_Alloc_IE(), is introduced to dynamically allocate or de-allocate a CQICH to an SS. Once allocated, 
the SS transmit channel quality information on the assigned CQICH on every subsequent frames, until the 
SS receives a CQICH_Alloc_IE() to de-allocate the assigned CQICH. 



Table 300— CQICH alloc IE format 



Syntax 


Size 


Notes 


CQICH_Alloc_IE() 0 { 






Extended DIUC 


4 bits 


CQICH = 0x03 


Length 


4 bits 


Length of the message in bytes (variable). 


CQICHJD 


variable 


Index to uniquely identify the CQICH resource 
assigned to the SS. 

The size of this field is dependent on system 
parameter defined in DCD. 


Allocation offset 


6 bits 


Index to the fast feedback channel region 
marked by UIUC = 0. 


Period (p) 


2 bits 


A CQI feedback is transmitted on the CQICH 
every 2p frames. 


Frame offset 


3 bits 


The SS starts reporting at the frame of which the 
number has the same 3 LSB as the specified 
frame offset. If the current frame is specified, 
the SS should start reporting in eight frames 


Duration (d) 


3 bits 


A CQI feedback is transmitted on the CQI 
channels indexed by the CQICHJD for 10 x 2 d 
frames. 

If d == 0, the CQI-CH is deallocated. 

If d == Obi 11, the SS should report until the BS 

command for the SS to stop. 


MIMO_permutation_feedback_cy 
cle 


2 bits 


ObOO = No MIMO and permutation mode feed- 
back 

ObOl = The MIMO and permutation mode indi- 
cation shall be transmitted on the 
CQICH indexed by the CQICHJD 
every four frames. The first indication is 
sent on the eighth CQICH frame. 

0b 10 = The MIMO mode and permutation mode 
indication shall be transmitted on the 
CQICH indexed by the CQICHJD 
every eight frames. The first indication 
is sent on the eighth CQICH frame. 

Obi 1 = The MIMO mode and permutation mode 
indication shall be transmitted on the 
CQICH indexed by the CQICHJD 
every 16 frames. The first indication is 
sent on the 16th CQICH frame. 


Padding 


variable 


The padding bits is used to ensure the IE size is 
integer number of bytes. 


} 







544 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



CQICHJD 

The CQICHJD uniquely identifies a fast feedback channel on which an SS can transmit fast feed- 
back information. With this allocation, a one-to-one relationship is established between the 
CQICHJD and the SS. 
MIMO_permutation_feedback_Cycle 

This field specifies the MIMO and permutation mode fast feedback cycle. See 8.4.5.4.10.2 for fast 
feedback channel payload encoding for MIMO and permutation feedback. 

8.4.5.4.13 UL ACK channel 

The uplink ACK (Acknowledgement) provides feedback for Downlink Hybrid ARQ. This channel shall 
only be supported by SS supporting H-ARQ. The SS transmits ACK or NAK feedback for Downlink packet 
data. One ACK channel occupies half subchannel (three pieces of 3x3 uplink tile) of the PUSC optional 
permutation. 

The ACK channel is orthogonally modulated. The acknowledgement bit B A n CK of the n-th ACK channel 
shall be "0" (ACK) if the corresponding downlink packet has been successfully received; otherwise, it shall 
be a "1" (NAK). The k-th orthogonal modulation symbol of the n-th ACK channel, WjJ", (k = 0,1,. ..,8 and 
n=0,l,..., 1 -A^ c ^)is made as shown in Table 301. 



Table 301— Orthogonal Modulation for ACK channel 







0 


1 1 1 1 1 
1111 


1 


1 exp(j • y) exp(y • y) exp(j • y) exp(; • y) 
1 exp(; • y) exp(y • y) 



Then the modulated symbols are mapped to the subcarriers allocated to the n-th ACK channel, as follows. 



r ACK - 



where 



exp 
exp 



V n,k- 
v 3/ n,k- 



18 



if k = 0,1, ...,8 
if k = 9, 10, 17 

if k = 18, 19 26 



(108) 



CACK 
n k mapping symbol of the k-th ACK subcarrier in the n-th ACK channel, 

M^ C k K modulation symbol index of the k-th modulation symbol made from the n-th ACK bit as shown 
in Table 301, 
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n ACK channel index from the set [0 ... 1 - N ACK ], 

k ACK subcarrier index of an ACK channel from the set [0 ... 26]. 

8.4.5.4.14 UL-MAP Physical Modifier IE 

The Physical Modifier Information Element indicates that the subsequent allocations shall utilize a 
preamble, which is either cyclically rotated in frequency or cyclically delayed [see Equation (104) and 
Equation (105)]. The PHYMOD_ULJE can appear anywhere in the UL map, and it shall remain in effect 
until another PHYMOD_UL_IE is encountered, or until the end of the UL map. 



Table 302— OFDMA UL-MAP Physical Modifier IE format 



Syntax 


Size 


Notes 


PHYMODULJEO { 






Extended UIUC 


4 bits 


PHYMOD = 0x05 


Length 


4 bits 


Length = 0x03 


Preamble Modifier Type 


lbit 


0 - Randomized preamble 

1 - Cyclically shifted Preamble 


if (Preamble Modifier Type == 0) { 






Preamble frequency shift index 


4 bits 


Indicates the value of K in Equation (105) 


} else { 






Preamble Time Shift Index 


4 bits 


Indicates the value of K in equation (1) 
For PUSC, 

0-0 sample cyclic shift 

1 - floor(A^ F/ ry/4) sample cyclic shift 

3 - floor(yv T / r F7 /4*3) sample cyclic shift 
4-15 - reserved 
For optional PUSC, 
0-0 sample cyclic shift 

1 - f\oor(N FF j/3) sample cyclic shift 

2 - f\oor(N FF jtt*2) sample cyclic shift 
3-15 - reserved 

For AMC permutation, 

0-0 sample cyclic shift 

1 - fioor{N FF j/9) sample cyclic shift 

8 - floor(iV> F7 /9*8) sample cyclic shift 
9-15 - reserved 


} 






reserved 


7 bits 


Shall be set to zero 


} 







Preamble Modifier Type 

This parameter defines whether the preamble will be cyclically shifted in time or in frequency. 
Preamble frequency shift index 

This parameter effects the cyclic shift of the preamble in frequency axis, as defined by 
Equation (105). 



546 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



Preamble Time Shift Index 

This parameter defines how many samples of cyclic shift shall be introduced into the preamble 
symbols. The unit of cyclic shift depends on the subchannel permutation to ensure the frequency- 
domain orthogonality between the different preambles in the same subchannel. 

8.4.5.5 Burst profile format 

Table 303 defines the format of the Downlink_Burst_ Profile, which is used in the DCD message (6.3.2.3.1). 
The Downlink_Burst_Profile is encoded with a Type of 1 , an 8-bit length, and a 4-bit DIUC. The DIUC field 
is associated with the Downlink Burst Profile and Thresholds. The DIUC value is used in the DL-MAP 
message to specify the Burst Profile to be used for a specific downlink burst. 



Table 303— OFDMA Downlink_Burst_Profile TLV format 



Syntax 


Size 


Notes 


Downlink_Burst_Profile { 






Type=l 


8 bits 




Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


DIUC 


4 bits 




TLV encoded information 


variable 




} 







Table 304 defines the format of the Uplink_Burst_Profile, which is used in the UCD message (6.3.2.3.1). 
The Uplink_Burst_ProfiIe i s encoded with a Type of 1, an 8-bit length, and a 4-bit UIUC. The UIUC field is 
associated with the Uplink Burst Profile and Thresholds. The UIUC value is used in the UL-MAP message 
to specify the Burst Profile to be used for a specific uplink burst. 



Table 304— OFDMA Uplink_burst_profile TLV format 



Syntax 


Size 


Notes 


Uplink_Burst_Profile { 






Type=l 


8 bits 




Length 


8 bits 




reserved 


4 bits 


Shall be set to zero 


UIUC 


4 bits 




TLV encoded information 


variable 




} 







8.4.5.6 Compressed maps 

In addition to the standard DL-MAP and UL-MAP formats described in 6.3.2.3.2 and 6.3.2.3.4, the DL- 
MAP and UL-MAP may conform to the format presented in the following subclauses. The presence of the 
compressed DL-MAP format is indicated by the contents of the most significant two bits of the first data 
byte following the DL Frame Prefix. These bytes overlay the HT and EC bits of a generic MAC header. 
When these bits are both set to 1 (an invalid combination for a standard header), the compressed DL-MAP 
format is present. A compressed UL-MAP shall only appear after a compressed DL-MAP. The presence of a 
compressed UL-MAP is indicated by a bit in the compressed DL-MAP data structure. 
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8.4.5.6.1 Compressed DL-MAP 

The compressed DL-MAP format is presented in Table 305. The message presents the same information as 
the standard format with one exception. In place of the DL-MAFs 48-bit Base Station ID, the compressed 
format provides a subset of the full value. When the compressed format is used, the full 48-bit Base Station 
ID shall be published in the DCD. 



Table 305— Compressed DL-MAP message format 



Syntax 


Size 


Notes 


Compressed_DL-MAP() { 






Compressed map indicator 


2 bits 


Set to binary 11 for compressed format 


reserved 


Ibit 


Shall be set to zero 


UL-MAP appended 


Ibit 




CRC appended 


Ibit 




Map message length 


11 




PHY Synchronization Field 


32 bits 




DCD Count 


8 bits 


- 


Operator ID 


8 bits 




Sector ID 


8 bits 




DL IE count 


8 bits 




for (/ = 1; i <= DL IE count; i++) { 






DL-MAPJE0 


variable 




} 






if !(byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary 


} 






} 







Compressed map indicator 

A value of binary 11 in this field indicates the map message conforms to the compressed format 
described here. A value of binary 00 in this field indicates the map message conforms to the 
standard format described in 6.3.2.3,2. Any other value is an error. 
UL-MAP appended 

A value of 1 indicates a compressed UL-MAP (see 8.5.5.2.4.2) is appended to the current 
compressed DL-MAP data structure 
CRC appended 

A value of one indicates a CRC-32 value is appended to the end of the compressed map(s) data. 
The CRC is computed across all bytes of the compressed map(s) starting with the byte containing 
the Compressed map indicator through the last byte of the map(s) as specified by the Map message 
length field. The CRC calculation is the same as that used for standard MAC messages. A value of 
zero indicates that no CRC is appended. 
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Map message length 

This value specifies the length of the compressed map message(s) beginning with the byte 
containing the Compressed map indicator and ending with the last byte of the compressed DL- 
MAP message if the UL-MAP appended bit is not set or the last byte of the UL-MAP compressed 
message if the UL-MAP appended bit is set. The length includes the computed 32-bit CRC value if 
the CRC appended indicator is on. 
PHY Synchronization 

This field holds frame number and frame duration information. See 8.4.5.1 and Table 273 
DCD Count 

Matches the value of the configuration change count of the DCD, which describes the downlink 
burst profiles that apply to this map. 
Operator ID 

This field holds the least significant 8 bits of the most significant 24 bits of the 48-bit Base Station 
ID. 

Sector ID 

This field holds the least significant 8 bits of the 48-bit Base Station ID. 
DL IE count 

This field holds the number of IE entries in the following list of DL-MAP IEs. 
8.4.5.6.2 Compressed UL-MAP 

The compressed UL-MAP format is presented in Table 306. The message may only appear after a 
compressed DL-MAP message to which it shall be appended. The message presents the same information as 
the standard format with the exception that the Generic MAC header and the Uplink Channel ID are omitted. 



Table 306— Compressed UL-MAP message format 



Syntax 


Size 


Notes 


Compressed_UL-MAP() { 






UCD Count 


8 bits 




Allocation Start Time 


32 bits 




while (map data remains) { 






UL-MAPJE0 


variable 




} 






if !(byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary. 


} 






} 







UCD Count 

Matches the value of the Configuration Change Count of the UCD, which describes the uplink 
burst profiles that apply to this map. 
Allocation Start Time 

Effective start time of the uplink allocation defined by the UL-MAP. 
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8.4.5.7 AAS-FBCK-REQ/RSP message bodies 

The format of the AAS Feedback Request message body is shown in Table 307. 



Table 307— OFDMA AAS Feedback Request message body 



Syntax 


Size 


Notes 


OFDMA-AAS-FBCK-REQ_Message_Body() { 






Frame Number 


8 bits 




Number of Frames 


7 bits 


■ 


Measurement DataType 


lbit 


0 - measure on downlink preamble 

only 

1 = measure on downlink data (for 

this SS) only 


Feedback Request Counter 


3 bits 




Frequency measurement resolution 


2 bits 


ObOO = 32 subcarriers 
ObOl = 64 subcarriers 
OblO = 128 subcarriers 
0b 11 =256 subcarriers 


reserved 


3 bits 


Shall be set to zero 


} 







Frame Number 

The least significant 8 bits of the frame number in which to start the measurement. 
Number of Frames 

The number of frames over which to measure. 
Feedback Request Counter 

Increases every time an AAS-FBCK-REQ is sent to the SS. Individual counters shall be maintained 
for each SS. The value 0 shall not be used. 
Frequency measurement resolution 

Indicates the frequency measurement points to report on. Measurement points shall be on the 
frequencies corresponding to the negative subcarrier offset indices -N US J2 + n times the indicated 
subcarrier resolution and corresponding to the positive subcarrier offset indices N US J2 - n x the 
indicated subcarrier resolution where n is a positive integer. 
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The format of the AAS Feedback Response message body is shown in Table 308. 



Table 308— OFDMA AAS Feedback Response message body 



Syntax 


Size 


Notes 


OFDMA-AAS-FBCK-RSP_Message_Body() { 






reserved 


2 bits 


Shall be set to zero 


Measurement data type 


1 bit 


0 - measure on downlink preamble 

only 

1 = measure on downlink data (for 

this SS) only 


Feedback Request Counter 


3 bits 




Frequency measurement resolution 


2 bits 




for (i=0; kNumber of Frequencies; i++){ 






Re(Frequency_value[i] ) 


8 bits 




Im(Frequency_value[i]) 


8 bits 




} 






RSSI mean value 


8 bits 




CINR mean value 


8 bits 




} 







Feedback Request Counter 

Counter from the AAS-FBCK-REQ messages to which this is the response. The value 0 indicates 
that the response is unsolicited. In this case, the measurement corresponds to the preceding frame. 
Re( Frequency_value[i] ) and Im( Frequency_value[i] ) 

The real (Re) and imaginary (Im) part of the measured amplitude on the frequency measurement 
point (low to high frequency) in signed integer fixed point format ( [±][2 bits]. [5 bits]). 
RSSI mean value 

The mean RSSI as measured on the element pointed to by data measurement type, frame number 
and number of frames in the corresponding request. The RSSI is quantized as described in 8.3.9.2. 
When the AAS feedback response is unsolicited, this value corresponds to preceding frame. 
CINR mean value 

The mean CINR as measured on the element pointed to by data measurement type, frame number, 
and number of frames in the corresponding request. The RSSI is quantized as described in 8.3.9.2. 
When the AAS feedback response is unsolicited, this value corresponds to preceding frame. 

8.4.6 OFDMA subcarrier allocations 

For OFDMA, F = floor(S/l ■ B W8000) • 8000 . Subtracting the guard tones from N FFT> one obtains the set 
of "used" subcarriers Af^. For both uplink and downlink, these used subcarriers are allocated to pilot sub- 
carriers and data subcarriers. However, there is a difference between the different possible zones. For FUSC, 
in the downlink, the pilot tones are allocated first; what remains are data subcarriers, which are divided into 
subchannels that are used exclusively for data. For PUSC in the downlink or in the uplink, the set of used 
subcarriers is first partitioned into subchannels, and then the pilot subcarriers are allocated from within each 
subchannel. Thus, in FUSC, there is one set of common pilot subcarriers, but in PUSC, each subchannel 
contains its own set of pilot subcarriers. 
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8.4.6.1 Downlink 

The downlink can be divided into a three segment structure and includes a preamble which begins the 
transmission. This preamble subcarriers are divided into three carrier-sets. There are three possible groups 
consisting of a carrier-sets each, that may used by any segment. 



A downlink period will fo llow Figure 232. 
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Figure 232— Downlink transmission basic structure 



8.4.6.1.1 Preamble 

The first symbol of the downlink transmission is the preamble; there are six types of preamble carrier-sets, 
those are defined by allocation of different subcarriers for each one of them; those subcarriers are modulated 
using a boosted BPSK modulation with a specific Pseudo-Noise (PN) code. 



The preamble carrier-sets are defined using Equation (109). 

PreambleCarrierSet n - n + 3 k 



(109) 



where: 

PreambleCarrierSet n specifies all subcarriers allocated to the specific preamble, 

n is the number of the preamble carrier-set indexed 0...2, 

k is a running index 0...576. 

Each segment uses two types of preamble out of the six sets in the following manner: 

Each segment uses a preamble composed of a carrier-set out of the three available carrier-sets in the 
following manner: (In the case of segment 1, the DC carrier will not be modulated at all and the appropriate 
PN will be discarded; therefore, DC carrier shall always be zeroed. For segment 2, the last carrier shall not 
be modulated). 

— Segment 0 uses preamble carrier-set 0 

— Segment 1 uses preamble carrier-set 1 

— Segment 2 uses preamble carrier-set 2 

Therefore, each segment eventually modulates each third subcarrier. As an example, Figure 233 depicts the 
preamble of segment 1. 
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t 

0 

Figure 233— Downlink basic structure 

The PN series modulating the pilots are defined in Table 309. The series modulated depends on the segment 
used and IDcell parameter. The defined series shall be mapped onto the preamble subcarriers in ascending 
order. Table 309 includes the PN sequence in an Hexadecimal format. The value of the PN is obtained by 
converting the series to a binary series (W k ) and starting mapping the PN from the MSB of each symbol to 
the LSB (0 mapped to +1 and 1 mapped to -1, for example for lndex=0, segment =0, W k - 110000010010..., 
and the mapping shall follow: -1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 +1 ...) :. 



Table 309— Preamble modulation series per segment 



Index 


IDcell 


Segment 


Series to modulate (W0 


PAPR 
(informative) 


0 


0 


0 


OxC 1 2B7F736CFFB 1 4B6ABF4EB50A60B7A3B4 1 63EA3360 
F697C45075997ACE17BB1512C7C0CEBB34B389D8784553 
C0FC60BDE4F166CF7B04856442D97539FB915D80820CED 
D858483 


4.33 


1 


1 


0 


0xA9F7AClBD0A4BD694D3EDC2991CC3B2D24BF26A223 
46F8DB370202CDA25D382D4 1 1 9A AC676E320A938 A95762 
C4078689B6024E477F0EDA8F5631O6F0D7OEBE3E0O6F75B 


4.21 


2 


2 


0 


0x56531FBB87033E4F362273BAF0F8879B45B9F19143E549 
4F7B025D138DF057756DE625196292AF6D28FD0AA08453 
E5B987 1EDAE3E680B848C67BFBD7ADE73CFBBBA4E8 1 1 
91267A 


4.32 


3 


.3 


0 


0xB397F552DEB27 1 7CC 1 9DDF0D59674DD6F6D3866A3FD 
023A009F592B56460660F1D585E3078AFE272D97FDF42807 
90C3A9E5FCF9910895E9DAF2BF65728F7390C930428B4E6 
793C 


4.36 


4 


4 


0 


Ox 1 BD4C84B42DF6B7DC53F6C7B8E223 A3B 1 6D8E2 1 4CFA 
5469A8D22246BCF297E5F92159406608B8A0BB55EF64A85 
B1241C5CDFA048CF0492AB3BCF46A8E8FE986F06E246F1 
E06C68 


4.49 


5 


5 


0 


0x4E00947B6722B09389EFB4F6951C488B368393E82549483 
59287441709C6F0E4463C067733C42A7FA89645D7D69AF2 
ACE5402AC473DBF2C75ECB8B630BAF4B27F282249BD52 
660 


4.49 


6 


6 


0 


0x494CAB6935E10DB5D6E985997849EA45F0D5E2EDF767 
0B FD96435 3 1 760D9F7CC0 1 DD63BEEDFECB7E806F3F 1 89 
291C074C8289D93A95324D131391E23EB9CEEAB0E789DA 
1F5B9CB 


4.35 


7 


7 


0 


0x4C5F10264D6C5085346E86BF8567294523ClB683D2A220 
D9BEDCEBBA1 10620BB53ECB0338BE7 109240E22EC902F 
C A05F97338BB9DF2DDEAF7C795BCB 160BD4F0 1 A6DBF2 
A729373 


4.48 



t t ! 



AAA 



1695 1698 1701 
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Table 309— Preamble modulation series per segment (continued) 



Index . 


IDcell 


Segment 


Series to modulate (W^ 


PAPR 
(informative) 


8 


8 


0 


0x79797D9AB260C20D5A460CDC49B2D0285E095E835EAF 
2ECC74E010DD8A53797CE0EC2EEBA51E779AA6B749B8 
E69FFDD632AC79D64143467E73017113BCDF45E787D0A9 
EAC3D22E 


A AO 

4.4o 


9 


9 


0 


0xAlB9AC2C3D5B9BAAE5067C9E4A83C167076BE7D8699 
ACA710FF205DE774FD46DD5F7851A2149D61E57152B98B 
6AF4194B6FED90ADA008D1D5F8DD87E8060F943BC9124 
CI 999236 


A CC 

4.55 


10 


10 


0 


066E5FA91D00D63B26036009F8C69142B9D936396FF9E137 

86478BBFF5DE6F184A0F844663950F69AFEDEA93CA4A3 

BF94B13175A2CBBA3836A34E5CE6D763767B35515F332D 

836 


A C A 

4,54 


11 


11 


0 


0xF443E9FBF763DA2A5137A57C7DA504D194EC1797AD3 
3365BAC2F0C94541F4D47A664A7A17308C37E06BB0826F 
F999C15EE430A3CC54159E3B7EEBD5FF307BB24A939AB 
261E2B3C 


A CI 

4.53 ■ 


12 


12 


0 


OxF38BE6D2108483C056088C5E7C8BF92E9C973EOB2ADA 
9342B46C06C4C25 1 6CF7B9E6043E2947 AD40F4 1 734E02A9 
ADCE9C70E03C4D50E7EAC73DAD56BDBB796289DDCC3 

57776DE2 


4.55 


13 


13 


0 


Ox 1 04 A A84E70B 1 63 A42654 A45995 1 82B 1 C3DD63F4BCB09 
ECA79A0D6D2D2A784DD60 1 57945983 10BE087F750 1 9227 
F899744B7C73A9008C83C0923D5DC154FB2DCBF8983E70 

9BCDF3 


4.54 


14 


14 


0 


0x0B49A507AC4EAAC7551FC4B00658A28D951FC81723C 
C1C024AAC6A9DE9686383C28036C762C020012D797866D 
E589B36BB95DFDAC2B3D0AB9DDE0B9719918062FE824E 
063BA3EC 


4.52 


15 


15 


0 


0x64C14C7D3725A74923E6B2FBlC3BDC77FEE58CB0AF3 
10EC37F22C93E2C809AE8410963E6CF5E7E192502960F027 
2244A3 1D2CDDC657BCFF422E29C50D5E82EDCB445791 8 

1BBA4D 


4.41 


16 


16 


0 


0x210D8A8E602BD53F981BE763E10F4730BDA53D2F89BD 
1D91C8F2DD5B96732935F789F643911937344E9F2ECF3222 
AB076BC2B5EE407DC58 1 F0EF9FFBD56D 14D 1 37A04 1 8A 
DA06D0 


4.47 


17 


17 


0 


0x88960A88E3F79C95D525DB49679C20A736D0E9E4DlFC 
B9DE7735AE1E947F4E93637E98143D6BB779394C58F2AC 
5A9BD7B2074E98F1B2026B67B507CAAD8076082B09FB34 

5DA02D 


4.54 


18 


18 


0 


E6D60C919AADAD00569E5F902D40500542631FB729FC3A 
F456C9A47E3EB967D51E09D712D8D49A028E738BEC9006 
1B089C9F 


4.55 


19 


19 


0 


0xA063E03DE6C137F3FC56F970052BCF7333C8451BF5D18 
D1B9AA5342E79C25451C1D862ECB5CFF21B7CC203817D 
78C192EE1A68976652E1740C4B123552C85CEE524A2AA90 
D428B 


4..66 
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Table 309 — Preamble modulation series per segment (continued) 



Index 


IDceU 


Segment 


Series to modulate (W^ 


PAPR 

(informative) 


20 


20 


0 


0xD2A7F 126A9599093A9262E66A247 1 B6B6A2ACB0A4330 
A 1 1 401 1 366CBC3B0 1 CC85CF 1 9 1 5982BE64DDDF8EE A0985 
D8F47BC4B41 38 1 C5827 1 C30578960EEFB054F299C72 1 B8 1 
D5DFE 


4.52 


21 


21 


0 


0x7682842351C76BC8E4A7EA4EDDB0F92F6E876FCFDFD 
AA4987B38FC4FA47C52EF0070DCC8C77FA622B20BEBC2 
3730 1 1 660B4960EF49FB5E5 1 9D79E 1 2029C7D 1 3C553EDC4 
8564 A52 


4.58 j 


22 


22 


0 


0xAD6143F875C4C965A7018B8230D8D50297DA2C54A6D 
D52EA6207620F4A66EAFEBC4DD56233FF5DF78FB20CD7 
4ECC6D01232FCFB9CBD36B3381F0224EF5DE7BE0AFEF0 
A1AEF3D82 


4.63 


23 


23 


0 


Ox9A14B722E05D8455A80B4AlBlD12A30ClE25D9488BA 
D486C639CC7BDF651E957E041A7C092A916BF3E3642121 
350579B3F8F8F4A30570237E722A6DC532A26F4FD4A0767 
D91A8B 


4.72 


24 


24 


0 


0xE6944DEEE85D75E3C5D9B90912177D8A85909D87AC21 
FA4A5 1660E1 1D30DBEED391E5972D0O0EF4E9BF3OB63B 1 
8C0285FE4 1 5 1 A423 1 C289A824D405 1 42B7C775C3C68D8 A 
A1D8A7 


4.64 


25 


25 


0 


0x9927326FDFEC99025AAlB79364F06C63AFE4A96C2A20 
FF8B 1 5 1 EF97 AFD08E 1 6 1 EA6B 10 A 1 FA7479452 1 DE02645C 
256 1 D3BEA5D382AE3707 11261 9403E23C724B36B79 1 DFA * 
FEAA3A 


4.52 


26 


26 


0 


0x03C19F38117AE5BDADF256FB4A223A660E2D626598F5 
6580E30FA2E40A521FE5D68709B7F62E4C08CB9A26AE12 
002AD2FA9DE6C2B298538556EFBA71626A02745C3DB5E 
BADD3F3 


4.43 


27 


27 


0 


0xCBA035B40EB7C8A3A048C490E38935CBF956C58AFC8 
9 1 A6C 1 1 2C032 1 CF52624989 1 5794DC A703BD3 1 A96FF4C06 
36F2D5E9F17C23F1486B90715597D565017CB8E424DE9A8 
E464E 


4.76 


28 


28 


0 


0x9321B7BE085143649644BCDF8342FCAD3462DAlC5722 
27B039BBC6F58B52EEED2ACFB38F9CAA2B A2F5 1 3 A87B 
1 ODD 1 9DEFB6 A9972EE 1 2D8 1 C83DBFB3CFCC93D35ED25 
2D0E1A3D1E 


4.67 ! 


29 


29 


0 


0x215F6EA7C7F95C74828485AABF6A5F54FD32DlA8F4F6 
F1C20E6CDB57FA81ED70DFE44ACCD4B37D4F01AD3BF3 
1 AFBB3 8 A4DDBC6 1 3C8809E46C 1 247222E504 1 D8CDC08F 
37F679878 


4.51 


30 


30 


0 


0xB5 ABE9FC32960003 1 F97DEA8CF5B 1 7EC432BB9F1 9082 
A3CFA2682AAF121EE855873119A78869AF988BD90C64A7 
F31224727D22F74D7499AF6CD3B649C54AED6DC84DD8A 
B876B84 


4.74 


31 


31 


0 


Ox956D097E914338D226020B8A3BA5B3BB8733A9723CF19 
485DD9D22670B 1 328B825 A6B A 1 54586EDE60EB328 AF8D 
F 1 14 1 82EDAEE40 1 620 A 1 E870BFFFF430922893C 1 F54A87 A 
90BD3 


4.78 
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Table 309— Preamble modulation series per segment (continued) 



Index 


IDcell 


Segment 


Series to modulate (WfJ 


PAPR 
(informative) 


32 


.0 


1 


0x25 1 D994 1 0 1 EDA04D8B DOB 8EA6FA20 AE590C2CC 1 99 AB 
083C6AE61F091F2DD41D989EC164B1481D611BE9CEA009 
4AFE9DB56A4763F55B26E54EAB73ACD7D4BBA64C1421 
BC3EB9D67 


4.61 


33 


1 


1 | 


0xll3A5FB9C529AADC9CABlFB882905601778659CDB69 
AFCBADDF8B42314A7985B5F87C20692309D350454FF932 
6481683FADAE471 1DD0CC5DACEDF7CD5DF1 177D60EB 
A4DBE657F1 


4.68 


34 


2 


1 


0x9F08189EFC6B5DE6C2CFDCD13195DE077586B8EE01E0 
OB6468B10A53FAAC1DD846E2A01681980D444B6ADOD34 
C34EC9CFD9341507878EC9FBAE498F5A20614BDF3E4B22 
DD285E6 


4.63 


35 


3 


1 


Ox3ECD476669A04A260414FD16F3F525AA060F20ADD933 
4A29A9D9F90618916EF51840C8F53AB596297F0782BEF42 
6E8B8539C9FDE970455B58F533FDAC1711DE6310E7596E 
D285E 


4.58 


36 


4 


1 


Ox3D6BD09A3DBD9ECCClC584E71C87221CD266087C7A6 
92D3EFF2D5F84DF2011EA3675853A61CD75D23600F8C115 
E03406AF914938170256B86DA5646CE0211FFDCD76A9A5 
E8D840 


4.68 


37 


5 


1 


0x27F0DA91D4ADlF39F0EAD459E2705CB2CA029A8E575 
92F 1 697877 1 99FF707D04 1 1 D6068 A0664594D89568460F268 
A225BB2AC0ED043659D779EA84656DEC0322F8C0CB 1 1 1 
AD2C8 


4.60 


38 


6 


1 


0x616FBCE479AAAC98B483FCF6EC06BBA84580EA98FA5 
17B3065A418CAF2C965B7AF2E7866B257390517016F25214 
90088193372879FAA8954651E7B3C80BA1725CB781726F32 
328 


4.71 


39 


7 


1 


0x3577 1 4863C5F477BE963806EA9D6EF6350B AFC 1 C 1 83FC 
C6BB47FFFEAA9FFD863589 1 8F6 A2 1 8266D624CA07092EC 
24466C7F7 120C 1 887 A3F59A48EB AB67F24A6E8930B862F5 
09A3 


4.60 


40 


8 


1 


OxABE49D0F8B9C8406BD7OB3FD83758768CDBA98164B9 
29A 1 E A 1 8D59BD44B80F9BBEF9D 1 CE5 1 E4EE 1 CF2 1 F6CC 
F18A7D4A92C26C121A22FC95663F0B55B892CF7D3D6581 
2A503DA48 


4.63 


41 


9 


1 


0x6898A2FC8C36DF0B84380FBCDE70812390B644E3B5BE 
A87D76C9123477638B331BEBC075664EA58C15680263664 
C48BF3411C3C13789C504A01FB4C7B9AC86AA524075E52 
C6A90 


4.65 


42 


10 


1 


0xE7709988D2D2DoABC6CEFB025FrCArCA4CUb/DL,oo33 
29EA439B75229ECE88FB5BD5D3BCA17C25BEB6575D932 
D01B5A63E044102E208C071C734EBA55712E122822ED2F2 
B379A11 


AHA 


43 


11 


1 


0xE49DCC8627542BA30FA500DCC23EEBF5A54B490EE76 
32C6BE57C724C3E74CD199930AB1D929D425185E2E1220 
CD2300F487392F4DC29416D332F13F8E760571D99617B263 
F387D 


4.66 
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Table 309 — Preamble modulation series per segment (continued) 



Index 


IDcell 


Segment 


Series to modulate ( Wrf 


PAPR 
(informative) 


A A 

44 


12 


1 


0xEE4CBD9B0EC65DE6DA78A2A205E5908B74127BDE612 
A9BD2D8F0C6A2B9E675401A9DDAA30FF9A55E87DAFFA 
3A33E5 3 A A A 1 D96 A60B326D7F6FA 1 47098DD825BD0FB 1 3 
ADDFE01569 


4.65 


45 


13 


1 


OxAD7DAD0BCA42DEDAFCCF7E57DC58D00E69 1 E8 1C04 
B98B2EDB66C66570B204B8352A08744D8A603C2A7769C7 
A9EE93 8 1 89 A45737B8687 1 E5C4025EE594D827C603E3 A49 
FD45519F 


4.58 


46 


14 


1 


0xF8F29BA0D2FA2D529EAF2CE9383E614F5AE8CA06658 
DD039AB2C9912DFC7CD1BA9744339E537850B7E4EA564 
819772D3320B1C7BA73EC24D90B8DCE17EA5DAD53771F 
68B050F43 


4.68 


47 


15 


1 


0x9CC0ECC9E7E8940DFED 1332AF492CFD39A2 1 F2820394 
EF05230 1 9EE5290A2B428 1 FF032C238 A6BE4 1 1 1 6C274E9 1 8 
F34F3 A27B5F 147E 1 0D4 1 65 8CDC7EFEDC3 1 35255C2B83B0 
AE6A 


4.81 


48 


16 


1 


OxFCE9C41A74CBB56634447836109869E557C5AOFAAlD4 
566E36A5 1 258CE6D096FBD3E0B7 1934 18D9DFCBD27693F 
8A5072425D4E3F33DB5AB45B1EF3E11A6730BED42961DF 
0354CD 


4.72 


49 


17 


1 


0x7941B66A275FB8F0BAA8EF7FFCC36AAA660113B66BE 
476D629AE5 1 2E48934 1 F6C9F84EC1 BE 1 C05CA3C850D20B 
1 A 12 AA9C94E 1 A654 1 C29A9B4BCD4 1 B94460DEF2E9643 A 
DCE86728 


4.62 


50 


18 


1 


0x0A9 1 F3902 1 3C9B2ED372B A 1 9FC42EE85 A AB25 98B5 8D2 
F7 1 84E A920546D6 A8 1 ED3 1 655 1B74B341E238A7FB83A4E 
F7D9EB0939B7771A6F4D0AF1F72752FE3234793D3CDC19 
BDFE08 


4.85 


51 


19 


1 


0x96949 ACCD785385AE8DE99CE42BBB73B996A886115A7 
8D0606AEC14D2E46E849BF88F9A2E17C2494704F1020CE 
F85FFDE 1 6B7483DBC6A 1 30488E3 AC5 86E528 AO0B90 1 347 
76E08C 


4.59 


52 


20 


1 


0x53FFBA26676A4FDlA6C30B8E4EA02DF535C922978CD 
24F6099C25003567F207CC5851656C5FD0D3F071942A16F1 
DB48DFBC26B ACC 15A1E61 8FF35F3DC3E 1 4 1E3666BCA5 
07ED72E 


4.70 


53 


21 


1 


0x7F32 1 9 ABE 1 389DBED8FC2F 1 C9C0FCE 1 974E7 1 C224E 1 9 
22F4CAD42E40AF15A5ECDB14221480F964E67BBD345C4 
4DC A0853548B399E3DF4D054D 1 76C0804D1 B 1 154 152BE9 
73A8896 


4.66 






i 
i 


102A79F5EB5EC258 145 1 1 BA5DD2FE9FB9699E7ED76F965 
B24748AE1A4A3A590F4F13E4722CCE399006F79AD8CE67 
3178F7 


A OO 

4.00 


55 


23 


1 


0xDB74EFA478268CDDE2596ADF9410FD83FCEDBB07C6 
DEC7 A3422 A 6CC66EF90 1 C 1 534EC2 A83E 1 A89B A207C72 1 
ECF3D42918FF40B3863379FDF3CED7A9CC86E348CAB03 
2F8FAAD9CD 


4.59 
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Table 309— Preamble modulation series per segment (continued) 



Index 


IDcell 


Segment 


Series to modulate (W0 


PAPR 

(informative) 


56 


24 


1 


0x5811 ADD9240A7B3AF35CACA6EFCCF4090A54bBh33D 
E54C077 1 92354DDEB8 1 CC968D 1 8354090B09D7472C83E 1 6 
96E 19545F08 1 36EF20CD74656BCD3 1296066E03CC89E22E 
47CF47 


4.oU 


57 


25 


1 


Ox871ECE60EDD2E19360D13862A15242250635774424B224 
65B3EF625E72072B7C45D81076DB4A5BFD5BE146F15CA 
A80DA031763DAC23BBBC54249E9878EC465F3EABE0B7 
AA497B8 


A 19. 
4./0 


58 


26 


1 


0xD8259B AF89D3E 1 3242CC 1 CDB A9C028 1 A0991 9D24ECF 
5BA83CDCD81E698EAA37DFE3E5802B3395B80A3DE91C 
F6C4BE2D34BBE985EE4041C4290D0A9185F115C963AD53 

6E4133426 


a nc\ 


59 


27 


1 


0xl2O3AlFD3F7B8E9D97A3812D4375D42BC9E8FOE393BD 

669A8099407EC0356DC45FEF848C98F3EF32A9A850CC67 

CE432339CBAF38BBA7DD0C94BC03B4704866509255E284 

50E459 


A 01 

4.y l 


60 


28 


1 


0x6A78A3F0DC5E4FA504580C37F5416BCC4A2BD51FClA 
71471BD1433EC3DD924E7130A7B2B331AB0B4AF6CF94C 
045A9C246965F46478D939795887EE3320BBC2D5DD5FFB 

06F894E8 


4./3 


61 


29 


1 


0x3042F24E050BAB38880A07BDE5D28AEE4AD59E0D71A 
B59824122E80F8FF67BEA1ECC865F50B25CF5095C642B80 
0E6A4D 1 32B49E5968DEBDD A029A227 AF332CF034BB937 
B471603 


A 1A 

4./4 


62 


30 


1 


0xC82853465FBB213A85A52888464E5D38D997F6C31966A 
94B452A2DE853CE38010BF9EA930BBD318189D5D2D0BD 
B4465248A2E8B481021531BE01F5E0FF1BAB75370C57B36 
BE6E9 


4.oU 


63 


31 


1 


0x2B 17EC947632DABA3 A2E1 1022033F20F873032F5 1F0647 
1 1 1 1 1D0C215E9E84C 1 1 A9E70950977527960700B37C6FECC 
A57C35A91873C935D7EDC22CB44DCC251396173CAC82B 

912 


A £1 


64 


0 


2 


0x83FC05D6DED982EB95B06E16C91EF94B441BBD4868C0 
9E9B3A251AD72427F2124607E151796070C2819E395EB68 
A2C597391636333A7E492B70D8EA7397FFA1B28C20E0820 
CC45 


A OA 

4.89 


65 


1 


2 


0x45 8 1 8FB AE49B983DB9B8FBEA 1 E8 1 6823430CE47BD 1 59 
3 173605CA255CCCCAE73C7283336BCBC94 1 33DCA64D67 
5BBA848A3E1C2EEE35D6085F06E72EAA696FBED6EA545 
F27D3692 


a on 
4.89 


66 


2 


I 


nvAnns74^P4S9ArFfiRnr>FP4A9F62S3BF4B467C93ACFF0 
F663A3F5949F15A1D266DEB0D26EC16D2A083F830E878A 
0300D74CFA3266CBBF3F0244ED56344D6AD5D887B3179C 
E56890D 


4.74 


67 


3 


2 


0xE52F56367EA45E4683E020856D05D08391D3D84766CA2 
253 1 B3EC6BE682E76B6ED7BCAABC3 AB6BDE32C4F700D 
4CDFF26F79AE16499D2B70EC389AC3ED5E02FDF5C43B2 
96CF965D 


4.75 
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(continued) 



Index 


IDcell 


Segment 


Series to modulate (W0 


PAPR 
(informative) 


HQ 
00 


4 


Z 


UxC5C62E3A9 1 1 A0F28BF6A67E1 DA2486FED7 1 1 0B08F0A9 
34C930AA035290D098857ECF3A069203A2560DADD50168 
02D9C1596526C7F1DA7C7B53360B0A673AA8634FB94D58 
38DC3E 


4.77 


69 


5 


2 


0xF9E176A9837BF970D5FD51732ECB8D90FBD12F62B62F 
938BE079 1 5B ABB0C6596080C832CE7FF9 1 4C849B9DA66F 
2380F3058F66340A34CA43583EC8EDC1E5CB5A2A25436E 
72292D 


4.64 


70 


6 


2 


0x5C26DB2489BE5 1 97B20CD6B38B 1 8 1 B7789DCB9088 1 A 
AC4B43 1 7B2F40B44884 1 44A 1 B 1 5BCB53C8E30FEC4 1 986 1 
C54B56 1 58D97 1 9E448B8 A8F455F5B 1 1 6275D796329059CD 
F682D3 


4.64 


71 


7 


2 


0xEF35242D5C426ClEBD9563A761CFBFllA531ACB93892 
2EBBA5227D8292585B777783972DA79C853A2A 17860 1E6 
CFEA35380045B50EE628F13AE3EC5B72FED52F92F731BB 
594DE8 


4.63 


72 


8 


2 


Ox 1 7FB B 33 1 93C68 A 1 C A A8CEF5CB 9A7FDFA 1 E89994F 1 77 
9D2D0DE69DE75A6B338A07635C8OA58722BB01398252F6 
C46AB7AEA79A6FC05F383F89ED65C49A2B9FB0D82A6E 
C03DD61F5 


4.82 


73 


9 


2 


0x076C 1 A 1 DC A870DF36638307F89 1 A52F737B A2B54EC0A 
D1FC5424D4F32DDE168ACE9B08653DEF8A23BF37CA3D 
306 1 38D698 A 1 33834BFB65BDE57048B9EEC630B 1 3E9 1 ED 
B1B52E8F 


4.86 


74 


10 


2 


0xA6800969ED0CE80A76F0F9BF7597ABE76DF60F243EE5 
29C63 AF72B AD6 AB8B3F0B09DFC 1 32C2B006827E55E352 
E3940A3BB8EE3526522ADF65AB76492BA41A393740A4B8 
5CD5113 


4.78 


75 


11 


2 


0x648 17485E539E02AAB074982A56DC6E867C6063 1 3 194B 
D66B4CF8B9E92C4F9FD 1 38B0E6EF36F699A3E6DCC4674 1 
B8CB16389EBA2C745398A30EA3102B6BA4FE9A8DA9605 
F929FF 


4.73 


76 


12 


2 


0xA3E438CB9EC48C4F4DD92C24950D0FlEAE7EEE92050 
1C2C8253 1 EDF8AEE35 3 1 F8D6B82D28C 1 FE073 1 088489FD 
2 1 5D 1 9202D AEE0A57E3E 1 634C7 A 1 BD5395C A64C64C 1 4E 
5C02D436 


4.68 


77 


13 


2 


Ox8F9339B406037D35 ADB9858576A62AF6 1 39FD2B02D38 1 
C7DF147A274E145F76DE5687AEC5BD3A715E0E893EEB6 
F24573D40 1 7B24B 30D4357E339B 1 0460 1 FC2DD 1 84DC9 A8 
F0D76A 


4.67 


/ o 


14 


9 

L 


CB5 A48B2E40 1 1 FD5EFB2 1 92C0FEDEE598372C7C06BEF2 
5F9B9702A8A9F0F52B197E9C910BB63F467E53BF46A45F7 
5C22F6 1 


4.09 


79 


15 


2 


0x914DE1436839A8E2FDD4EACCD645C3D29E522E19E005 
5A2510679A977772830824C7363461CBF5D662456DB798B 
A72AEB67FEB2FC28DAAD3FAE0048727CF6E9B237A8248 
9790D6 


4.84 
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Table 309— Preamble modulation series per segment (continued) 



Index 


IDcell 


Segment 


Series to modulate 


PAPR 
(informative) 


80 


16 


2 


0xA21E09CF0A98EB012E8914A3 lbb5tJb33r4 / ArooDUuoD 
CE2812F65C994A100EA41F732830EB3F6C6F7028BC9FB3 1 
C5D108F63315DEDE8EE82CF5DE892032688E1C367D8567 

A20ACA 


4.75 


81 


17 


2 


0x6E 1 1 F29 AE45 A99D74D9 1 1 7 7 / L) 1 DboU4y:) L/UAr l / udc / 
844FB7FCOA01247F3265F45D90A198ADCDODB98A3CE22 
ACF24A77C737E5BF99DCD7EFA6B6096B70C572996B62E 

7814236B 


4.72 


82 


18 


2 


0xE9F8FC 1 7F536 1DBCDD8F1 orzoCA9UDO 1 aVrotiDOUMo i 
C9E3B7FDBEA6D55FAB32A4310A52AD7AAA26D082B38 
D4D8A2FCB70A3C6A41675 15CA7 10E8F9B237F64B4D9A8 
C3CE8DF085 


4.70 


83 


19 


2 


0x11 FDC3B47 1 2 1 0 1 D7 1 7D0EDD / 5d ob AbUV 4U A A l o 5 :> U4^ 
A4C22A7959436ECCA5E08A4BF2BF9EEF4BCE5E3E48DD 
77EB418F6B84BF8937CE0CF9DAD247A64E9E850373FEE3 

D673F47C2 


4.74 


84 


20 


2 


0xE8784553C091233730B7DA7U4BoAUZBbi5b4DtiDutir4^D 
1 394E3B0E4 17FE3B57 1 E64 1 ADF2603402B8084 A2D 1 3 1 8 AF 
30CD95AD014D553408393AD345C05D62F435C708948233E 

F55B 


4.86 


85 


21 


2 


0xCDD6E932F9D2FAD131E7AE666B758CC4BboUCoUZ3Ub 
E14494D0F77E89A9BE726FAF8F9465AD0262D75C0A5374 
165A4FD2B4C602C0FF123F416360C112F6F95BD6790F81A 

CD858A 


A R4 


86 


22 


2 


0xA2702DE422E 1 CB AD A A8285 C 1 C3B 1 F4 1 D44S o r i u 
5466DF8070E604C733DE579755BCB8237C8DDB55A865B2 
13D1929EDC553CE9B55994985F9EBEDF2A9F524301E3DA 

0498817 


A 1(\ 


87 


23 


2 


0x54487F7BDCDF87B l AA252798D7E5AD97bob!)Zo3tJ /y»o 
B1E3E637852EDC83FA360676C04E35A1F5045B0A0B7DE9 
269F8A0E17F100D9AC78D873AE59BA0BA3E8AB3DDF92 

8AD58F9E 


A QO 


88 


24 


2 


0x3461 AA27EDE0A9F7955B469C41AE1485bbBbb4btf233i5 
0BBEB5F31BB36AC1E72CA6BF06B1E58F8612096CFA7289 
DEA8927B6368DC845DC8476074B83F3C1545A17F73EFE2 

14A3C9 


A Q1 


89 


25 


2 


0x2DDBBF4F82EB33001E46F08D17DB89DCb3C/CClz/bo 
B7D17839FE17A86F69178A1903E91857147348B491631336 
CB5D710382B59FF71416FEC2BAF0A0584F2155EEB71C54 

F84C4 


A RQ 


qa 

i 


zo 




0x762E2454401F66455358322AC0CFDF76EB18EFA9684Al 

0F0F527537A54E75FAD77BD89E0D47980793C7B79B922C1 

7792CC84BBEA81F6637192B74407A5B859EA1C873ED29D 

48FD 


4.76 


91 


27 


2 


0xF74BBB6C4B97071EBC19F3FE7840A67A3959BD993633 
5A4F8BD10C9CFD925D8388C31B947BFD318FFC8B0967C 
132A602BC31B29835AE070006A50554CF3C5F85D56832A 

BA9CA5B 


4.89 
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Table 309 — Preamble modulation series per segment (continued) 



Index 


IDcell 


Segment 


Series to modulate (Wrf 


PAPR 
(informative) 


no 

yz 


oq 


o 


0x06493F32F3CA54692CAE2579388B97D99B5D540DE7 1 F8 
B2405944C3A4FF18D7D45D4026DB9A867B85870BE6E23C 
9A8F84332D29B84B0303BB5 1 79DFD89B56A 14A37ABE053 
A0277 


4.94 


no 

yj 


on 
29 


2 


0xC88 A3 A3C02 1 1 A2 1 66 1 FD2B 30937F0A 1 87B 660 1 E366A8F 
C5BCD4210E2D5D3365B22D4D63273F822D89EC1745304F 
B A4D0A9295 A A5 1 2 1 2C 1 1 C9D0 A3 1 FAB B066289D8227B5B 
FDE8A0 


4.82 


94 


30 


2 


0xA81E35C6A92953C584FE5FB3B6FlB0A532E91A49DB70 
3D6E20D796F4532630C 1 D64DCEA580 1 88BDDAB37722 AD 
5DDCC9DFE7CFEDE15 1 8D8E2ACA842F3570C7F38 1EAB9 
C5E4D485C 


4.80 


nr 

95 


31 


2 


0x08C0CClC53E52AA366AFA63A48EBE2F7389C8A33CEB 
20173432B4828D68A547D4673E27F942FCA95942029CFE9 
F4 1 3FD ABE 1 D0BCF95022C5B99C 1 B229D 1 5 1 E9D3C AO A 1 2 
2F1BEEF 


4.97 


96 


0 


0 


0x9774EF2FA326 AB 1 9DE599803EB48740C90995 A4508064 
B6B19E58304229C5EDC578EF2C7030D4D2A01C9FB7618E 
7CB85648 1 6354DD6 1 EE 1 44D7C94 AFE8 AB966875 1 3 1 B9F7 
C18BB 


4.85 


97 


1 


1 


OxB9FBD947B7F9F3C8F6D3799E095BE558E6A2D0550COD 
D0DDC92CC7BB53C1FE80D536B1FAE89C9224E3504629D 
BF0C5457944A72769B7162FBB0BBE18189749D3E7E264CF 
BA7A0E 


4.75 


no 

98 


2 


2 


OxFDOE 1 5EC 1 40B2E878 1 7 AECC 1 6F 1 34B6622 1 C75 9CCF0E 
5000CDC0A3BADBB354D6845D745C22B1FB78C4205ABC 
F689495DE555CFFB4E4 164A9ED06E484A 192308A8CA890 
48A92C32 


4.81 


nn 
99 


3 


0 


0x28237E963DE488B97083F5A76BF5A861773DB61 108461 
A8CB8FAE918887897033207CEBFB83380BCC45748732F97 
52C86DEA5F5EE4BA741C6DAB59375DDCBDC6EFEDBC 
D10DF3C2 


4.84 


100 


4 


1 


0x023B7D4F9CA92DlE796C749B7664CCC4E8558C5CF20B 
F702E39BC3AE525A9FAA6581F4A22EF6829A44156DAE4 
CABEA9C6A41D5A4325C02980C8FA4621A7FD08D874C68 
7B68C706 


4.94 


101 


5 


2 


0xB7FF5E696A6923C504E2A64A097EB201EC52D7963D9D 
5DA4605 1 A4EB A8B2C2DB9FC4249 ABF2D8CCC88 1 F8 AA 
D20230F1B66D5D48CF2BCC5CADE7217E25FB9F6CB93C 
CE4111A33C6 


4.86 






0 

V/ 


F293086E 1 F48C7292BEC49 1 DDAF0E2CF02455 825089FCD 
985F77CDC4B561A6B8CD60CE31CBE6D467CFB4D153746 
FB7BE0D 


a no 


103 


7 


1 


0x91466310F3C4F355233B54C0AB8CB818780691443781B7 
1 AB6FB 8F6CD5 1 666 1 E39075B4207E55400E08 1 FD79C5246 
28C8FE 1 277BE 1 A6 1 65 ACB5F 1 54 1 58D26593FED2C48EF66 
268 


4.89 
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Table 309— Preamble modulation series per segment (continued) 



Index 


IDcell 


Segment 


Series to modulate (WjJ 


PAPR 

(informative) 


104 


8 


2 


0x45F8EB9235B6DC37577 1 B69789AFEEEBB806965E693 1 
A844F370CA14AA982635C54EA0BA973373D9FEO10993B4 
1EB8BF2C219B09AD13B4FE7FDC7295C5585883449067463 
7ED95 


4.93 


105 


9 


0 


0x3 AA7974B 1 8884644F5C782A5E7 1 AF70D9 1220EB0C468 
D079AFB7DF8033D3AB54BC728657D60B349C575C8B3DE 
C403A6D406E3FC4D016655D406B0B78389CEFCFF8A37D8 
67A44DF 


4.89 


106 


10 


1 


0xll4OB404D18CA769BDClE1188BBB5BFA3B87668D158B 
0875F4D4EE90ED42974B5A02A6AAFC6977EACD194CB9E 
8423E2931F2CD9AEF6C90F44EC626C56518360D20AE9721 
9FDE89 


4.90 


107 


11 


2 


0x76BE5786CE3C33A20A3776587F83E6C5280BD4DF20FE 
6C52D6BB582957E0CAEB988B32C3DB58027815D8618FB6 
FDB 1BCF9E87 1 D6C552AED5679BE98 1 89D95708FE92750C 
5ADE33 


4.84 


108 


12 


0 


0x33597C2D850E76B 1 16A82F95C766D2002B9822D52E09B 
1968BEF3DFD48D9F53D5296F1559BEB0BC7791C1F6B666 
EE68C605A2098A4A0BD57CE4F7A843068A8BA3BF0065A 
CA53C6 


4.95 


109 


13 


1 


0x894BllE2BB6884D9FFD78C6A8103F3BD44E6DFE48CD 
0DC89C63A4F8BA95858545D37EC1652AB2C073B99BC667 
D1F396C87F9902FCB08686E563D0D30EBF3D65756A63F00 
37C240 


4.83 


110 


14 


2 


0xDD08538B0939E852443E8801AB36C0FF50A6A0B63BBB 
E969F6A5A60BD6EEF19D070C3A14366EC789D39D07CD8 
891491FDB3C7EF57A0A310C8A4DC0A03D5DB84DA0D69 
11C4CBA9B 


5.03 


111 


15 


0 


0x7FFA4EF380C6504225EA6C8339E130DB7E69577E9C46C 
A494F66E2D5B25A256444606103A821615C2CDEA721D15 
3669E5025CDC37904CFC16A84E3B745079E5F1F3E08B068 
4BBB 


4.83 


112 


16 


1 


0x8A608CADlCDojrUo4orBZA:5yrDOlM /<*yy 
179C2C066F3F78F3B3EDEF15B7227C650BEFB63C950E1B 
52632D78D 1 A0F34552B A 1 38C877F09FCCFD305 1 1 E340F79 
4D154A 


4 QO 


113 


17 


2 


0x775CA156A4C0BDB8FE5FF3CFB91FC7BC9DEAFlB8B3 
362D06C9738D332868BBA3B18A0A907EE7918D955 10298 
E42F44B7BFC39D9E002EE24D1806EE0436B92DEC06DA3 
FDA2230F6 


5.14 



562 
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The modulation used on the preamble is defined in 8.4.9.4.3.1. 
8.4.6.1.2 Symbol structure 
8.4.6.1.2.1 Symbol structure for PUSC 

The symbol structure is constructed using pilots, data, and zero subcarriers. The symbol is first divided into 
basic clusters and zero carriers are allocated. Pilots and data carriers are allocated within each cluster. 
Table 310 summarizes the parameters of the symbol structure. 



Table 310— OFDMA downlink carrier allocations— PUSC 



Parameter 


Value 


Comments 


Number of DC subcarriers 


1 


Index 1024 


Number of Guard subcarriers, Left 


184 




Number of Guard subcarriers, Right 


183 




Number of used subcarriers ( N used ) 


1681 


Number of all subcarriers used within a symbol, ' 
including all possible allocated pilots and the DC 
carrier. 


Number of subcarriers per cluster 


14 




Number of clusters • 


120 




Renumbering sequence 


1 


Used to renumber clusters before allocation to 
subchannels: 

6, 108, 37, 81, 31, 100, 42, 1 16, 32, 107, 30, 93, 54, 78, 
10, 75,50, 111,58, 106, 23, 105, 16, 117, 39, 95,7, 
1 1 5, 25, 1 1 9, 53, 7 1 , 22, 98, 28, 79, 1 7, 63, 27, 72, 29, 
86, 5, 101, 49, 104, 9, 68, 1, 73, 36, 74, 43, 62, 20, 84, 
52, 64, 34, 60, 66, 48, 97, 21, 91, 40,-102, 56, 92, 47, 
90, 33,114, 18, 70, 15, 110,51, 118,46, 83,45, 76, 57, 
99, 35, 67, 55, 85, 59, 113, 11, 82, 38, 88, 19, 77, 3, 87, 
12, 89, 26, 65, 41, 109, 44, 69, 8, 61, 13, 96, 14, 103, 2, 
80, 24, 112, 4, 94,0 


Number of data subcarriers in each 
symbol per subchannel 


4 




Number of subchannels 


60 




PermutationBasel2 (for 12 subchannels) 




6,9,4,8,10,11,5,2,7,3,1,0 


PermutationBase8 (for 8 subchannels) 


4 


7,4,0,2,1,5,3,6 
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Figure 234 depicts the cluster structure. 




odd symbols 



#00 O O OOOOOill O even symbols 



Q data carrier 
^ pilot carrier 

Figure 234— Cluster structure 

8.4.6.1.2.1.1 Downlink subchannels subcarrier allocation in PUSC 

The carrier allocation to subchannels is performed using the following procedure: 

1) Dividing the subcarriers into 120 physical clusters containing 14 adjunct subcarriers each (starting 
from carrier 0). 

2) Renumbering the physical clusters into logical clusters using the following formula: . 
LogicalCluster = RenumberingSequence( (PhysicalCluster+13*lDcell) mod 120) 

In the first PUSC zone of the downlink (first downlink zone), the default used IDcell is 0. 

3) Dividing the clusters into six major groups. Group 0 includes clusters 0-23, group 1 includes 
clusters 24-39, group 2 includes clusters 40-63, group 3 includes clusters 64-79, group 4 includes 
clusters 80-103, group 5 includes clusters 104-119. These groups may be allocated to segments, if a 
segment is being used, then at least one group shall be allocated to it (by default group 0 is allocated 
to sector 0, group 2 is allocated to sector 1, and group 4 to is allocated sector 2). 

4) Allocating carriers to subchannel in each major group is performed by first allocating the pilot 
carriers within each cluster, and then taking all remaining data carriers within the symbol and using 
the same procedure described in 8.4.6.1.2.2.2 (with the parameters from Table 310, using the 
PermutationBase appropriate for each major group, PermutationBasel2 for even numbered major 
groups, and PermutationBase8 for odd numbered major groups) to partition the subcarriers into 
subchannels containing 24 data subcarriers in each symbol. Note that IDcell used for the first PUSC 
zone is 0. 



8.4.6.1 .2.2 Symbol structure for FUSC 

The symbol structure is constructed using pilots, data, and zero subcarriers. The symbol is first allocated 
with the appropriate pilots and with zero subcarriers, and then all the remaining subcarriers are used as data 
subcarriers (these will be divided into subchannels). 

There are two variable pilot-sets and two constant pilot-sets. In FUSC, each segment uses both sets of 
variable/constant pilot-sets. In STC mode (see 8.4.8), each antenna uses half of the pilot set resources 
compared to that of non-STC mode. Table 311 summarizes the parameters of the symbol. 
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Table 311 — OFDM A downlink carrier allocations 



Parameter 


Value 


Comments 


Number of DC Subcarriers 


1 


Index 1024 


Number of Guard Subcarriers, Left 


173 




Number of Guard Subcarriers, Right 


172 




Number of Used Subcarriers ( N used ) 


1703 


Number of all ^uhoarriprs used within a <;vmhn1 

including all possible allocated pilots and the DC 
carrier. 


Pilots 






VariableSet #0 


24 


0,72,144,216,288,360,432,504,576,648,720,792,864, 
936,1008,1080,1152,1224,1296,1368,1440,1512,1584, 
1 656,48, 1 20, 1 92,264,336,408,480,552,624,696,768, 
840,91 2,984, 1 056, 1 1 28, 1 200, 1 272, 1 344, 14 1 6, 1 488, 
1 560, 1 632,24,96, 1 68,240,3 1 2,384,456,528,600,672, 
744 816 888 960 1032 1 104 1 176 1748 n?0 1^09 
1464,1536,1608,1680 


ConstantSet #0 


4 


39 645 1017 1407 330 726 1155 1461 351 855 1 185 
1545 


VariableSet #1 


24 


36, 1 08, 180,252,324,396,468,540,6 12,684,756,828, 
VUU,y /Z, 1 U44, 1 1 1 0, 1 1 05, 1 ZoU, 1 33Z, 14U4, 1476, 1 54o, 
1 620, 1 692, 1 2,84, 1 56,228,300,372,444,5 1 6,588,660, 
732,804,876,948, 1 020, 1 092, 1 1 64, 1 236, 1 308, 1 380, 
1 452, 1 524, 1 596, 1 668,60, 1 32,204,276, 348,420,492, 
564,636„708,780,852,924,996,1068,1140,1212,1284, 
1 356, 1 428, 1 500, 1572,1 644 


ConstantSet #1 


4 


26 1 ,65 1 , 1 143, 1 4 1 9,342,849, 1 1 58, 1 530,522,9 1 8, 1 206, 
1701 


Number of data subcarriers 


1536 




Number of data subcarriers per subchannel 


48 




Number of Subchannels 


32 




PermutationBase 




3, 18,2, 8, 16, 10, 11, 15, 26, 22, 6, 9, 27,20, 25, 1,29, 
7, 21, 5, 28, 31, 23, 17, 4, 24, 0, 13, 12, 19, 14, 30 



The Variable set of pilots embedded within the symbol of each segment shall obey the following rule: 

PilotsLocation = VariableSet#x+6 • (FUSC_SymbolNumber mod 2) (110) 
where FUSC^SymbolNumber counts the FUSC symbols used in the transmission starting from 0. 
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Figure 235 depicts as an example of the symbol allocation for segment 0 on symbol number 1. 



tlltlltttt T tltttttttt ff ttttt HH I M -fft 

12 24 36 39 1692 

\Left Guard \ Data subcarrier ' Seated t0 311 subchannels Gu; 

Band (173 Band (172 

subcarriers) A subcarriers) 

T Pilot subcarrier 




Figure 235— Downlink symbol structure for segment 0 on symbol number 1 using FUSC 

8.4.6.1.2.2.1 Downlink subchannels subcarrier allocation 

Each subchannel is composed of 48 subcarriers. The subchannel indices are formulated using a RS series, 
and is allocated out of the data subcarriers domain. The data subcarriers domain includes 48*32=1536 
subcarriers, which are the remaining subcarriers after removing from the subcarrier's domain (0-2047) all 
possible pilots and zero subcarriers (including the DC subcarrier). 

After allocating the data subcarriers domain, the procedure of partitioning those subcarriers into subchannels 
shall be as specified in 8.4.6.1.2.2.2. 

8.4.6.1.2.2.2 Partitioning of data subcarriers into subchannels in downlink FUSC 

After mapping all pilots, the remainder of the used subcarriers are used to define the data subchannels. 

To allocate the data subchannels, the remaining subcarriers are partitioned into groups of contiguous 
subcarriers. Each subchannel consists of one subcarrier from each of these groups. The number of groups is 
therefore equal to the number of subcarriers per subchannel, and it is denoted N subcarriers . The number of the 
subcarriers in a group is equal to the number of subchannels, and it is denoted N subchannels . The number of 
data subcarriers is thus equal to N subcarriers * M subchannels . 

The exact partitioning into subchannels is according to Equation (111), called a permutation formula. (To 
clarify the operation of this formula, an example application is given subsequently in 8.4.6.2.3.) 

subcarrier{k,s) = N subckannels n k + {p s [n k mod N subchannel s ] + IDcell] mod N subchannels (111) 

where 

subcarrier(n, s) is the subcarrier index of subcarrier n in subchannel s, 

s is the index number of a subchannel, from the set [O...N subchanne i s -\], 

n k = (ft +13- s) mod N subcarriers , 

where k is the subcarrier- in- subchannel index from the set [0...N subcarriers - l] , 
N {S ubckannei)s the number of subchannels, 
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Psli] is the series obtained by rotating {PermutationBase 0 } cyclically to the left s times, 

ceil[ ] is the function that rounds its argument up to the next integer, 

iDcell is an integer ranging from 0 to 31, which identifies the particular BS segment and is spec- 

ified by MAC layer, 
x mod(k) is tne remainder of the quotient X/k (which is at most k - 1). 

and the numerical parameters are given in Table 31 1. 

On initialization, an SS must search for the downlink preamble. After finding the preamble, the user shall 
know the IDcell used for the data Subchannels. 

8.4.6.1.2.3 Additional optional symbol structure for FUSC 

The additional optional subchannel structure in the downlink supports 32 subchannels where each 
transmission uses 48 data carriers symbols as their minimal block of processing. In the downlink, all the 
pilot carriers are allocated first, and then the remaining carriers are used exclusively for data transmission. 
Nused subcarriers are divided into nine contiguous subcarriers in which one pilot carrier is allocated. The 
position of the pilot carrier in nine contiguous subcarriers varies according to the index of OFDM symbol 
which contains the subcarriers. If the nine contiguous subcarriers indexed as 0...8, the index of the pilot 
carrier shell be 31+1 where / = m mod 3(m is the symbol index). 



Table 312— OFDMA optional FUSC downlink subcarrier allocation 



Parameter 


Value 


Comments 


Number of DC subcarriers 


1 




N used 


1728 




Guard subcarriers: Left, Right 


159, 160 




Number of Pilot Subcarriers 


192 




Pilot subcarrier index 


9k + 3m + I 

for* = 0,...,191 and 

m - [symbol index] mod 3 


Symbol index 0 is the first 
symbol from which the 
diversity subchannelization 
is applied. 


Number of Data Subcarriers 


1536 





8.4.6.1.2.3.1 Downlink subchannels subcarrier allocation 

To allocate the diversity subchannels, the whole data tones in a slot are partitioned into groups of contiguous 
data subcarriers. Each subchannel consists of one subcarrier from each of these groups. The number of 
groups is therefore equal to number of data subcarriers per subchannel, and its value is 48. The number of 
the subcarriers in a group is equal to the number of subchannels, 32. The exact partitioning into subchannels 
is according to Equation (112), called DL permutation formula. 
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Carrier(s, m) = 



f32 k+[s + P hCi (k) + P 2fC2 (k)] 
32 -k+[s + P hCi (k)] 
32- k+[s + P %C2 (k)] 
32-k+s 



0<c { ,c 2 <N s 
Cj^O, c 2 = 0 
c x = 0, c 2 *0 
Cj = 0, c 2 = 0 



(112) 



where 

Carrier(s,m) is the index of m-th subcarrier in subchannel 5 at symbol n, 

it 



= (m+j*4<S)/m?</48, 
is the data symbol index in slot, n = 



m 
48 



m 

s 



C2 



is the subcarrier-in-subchannel index from the set [0 ... 47], 
is the index number of a subchannel from the set [0 ... 31], 

is the j-th element of the sequence obtained by rotating basic permutation sequence Pj 
cyclically to the left c, times. P]={ 1, 2, 4, 8, 16, 5, 10, 20, 13, 26, 17, 7, 14, 28, 29, 31, 27, 
19, 3, 6, 12, 24, 21, 15, 30, 25, 23, 11, 22, 9, 18], 

is the y'-th element of the sequence obtained by rotating basic permutation sequence P 2 , 
cyclically to the left c 2 times. P 2 ={ 1, 4, 16, 10, 13, 17, 14, 29, 27, 3, 12, 21, 30, 23, 22, 18, 
2, 8, 5, 20, 26, 7, 28, 31, 19, 6, 24, 15, 25, 11, 9], 
= IDcellmodN s ,0<c l <N s , 

Wcell |,o, C2 <^, 



In Equation (115), the operation in [ ] is over GF(2 5 ). In GF(2 5 ), addition is binary XOR operation. For 
example, 29 + 12 in GF(2 5 ) is [(11101) 2 XOR (01100) 2 ] = (10001) 2 = 17, where (x) 2 represents binary 
expansion of x. 

8.4.6.2 Uplink 

The following section defines the uplink transmission and symbol structure. The uplink follows the down- 
link model, therefore it also supports up to three segments. 

The uplink supports 70 subchannels where each transmission uses 48 data carriers as the minimal block of 
processing. Each new transmission for the uplink commences with the parameters as given in Table 313. 



Table 313— OFDM A uplink subcarrier allocations 



Parameter 


Value 


Number of dc subcarriers 


1 


^used 


1681 


Guard subcarriers: Left, Right 


184, 183 
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Table 313 — OFDMA uplink subcarrier allocations (continued) 



Parameter 


Value 


TilePermutation 


6,48,58,57,50, 1, 13,26,46,44, \ 
30, 3, 27, 53, 22, 18, 61, 7, 55, 36, 
45, 37, 52, 15, 40, 2, 20, 4, 34, 31, 
10,5,41,9, 69, 63,21, 11, 12, 19, 
68, 56, 43, 23, 25,39, 66, 42, 16, 
47,51,8,62, 14, 33, 24, 32, 17, 
54, 29, 67, 49, 65, 35, 38, 59, 64, 
28, 60, 0 


^subchannels 


70 


^subcarriers 


48 


N tiles 


420 


Tiles per subchannel 


6 



8.4.6.2.1 Symbol structure for subchannel (PUSC) 

A burst in the uplink is composed of three time symbols and one subchannel, within each burst, there are 48 
data subcarriers and 24 fixed-location pilot subcarrier. 

The subchannel is constructed from six uplink tiles, each tile has four subcarriers and its configuration is 
illustrated in Figure 236. 

% # # # Symbol 0 

$ % • # s y mbo11 
• # ft • Symbo12 

A pilot carrier &k data carrier 



Figure 236— Description of an uplink tile 



8.4.6.2.2 Partitioning of subcarriers into subchannels in the uplink 

The allocated frequency band shall be divided into 420 tiles, the allocation of tiles to subchannels is 
performed in the following manner: 



1 . Divide the 420 tiles into six groups, containing 70 adjacent tiles each. 

2. Choose six tiles per subchannel using Equation (113); for an example refer to 8.4.6.2.3. 

Tile(s, n) = 70 • n + (Pt [(s + n)modl0] + UL_IDcell)/n<?d 70 (113) 
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where 

n is the tile index 0... 5 

Pt is the tile permutation 

s is the subchannel number 

ULJDcell is an integer value in the range 0. . .69, which is set by the MAC layer. 

After allocating the tiles for each subchannel the data subcarriers per subchannel are enumerated by the 
following process: 

1. After allocating the pilot carriers within each tile, indexing the data subcarriers within the subchannels 
is performed starting from the first symbol at the lowest subcarrier from the lowest tile and continuing 
in an ascending manner throughout the subcarriers in the same symbol, then going to next symbol at the 
lowest data subcarrier, and so on. Data subcarriers shall be indexed from 0 to 47. 

2. The enumeration of the subcarriers will follow Equation (1 14). This enumeration sets the order to which 
the mapping of the data onto the subcarriers shall be performed. 

subcarrier (n, s) = (n + 13 • s)modN subcarriers ( 114 ) 

where 

n is a running index 0. . .47, 

s is the subchannel number, 

^subcarriers is the number of subcarriers per subchannel 

8.4.6.2.3 Uplink permutation example 

To illustrate the use of the permutations, an example is provided to clarify the operation of the permutation 
formula, Equation (113). 

The tiles used for subchannel s = 3 in ULJDcell = 2 are computed. 

The relevant parameters characterizing the uplink are therefore taken from Table 313. 

— Number of subchannels: N subchanne i s = 70 

— Number of subcarriers in each OFDMA symbol: N subcarriers = 24 

— Number of data subcarriers in each subchannel = 48 

— TilePermutation = {6, 48, 58, 57, 50, 1, 13, 26, 46, 44, 30, 3, 27, 53, 22, 18, 61, 7, 55, 36, 45, 37, 52, 
15, 40, 2, 20, 4, 34, 31, 10, 5, 41, 9, 69, 63, 21, 11, 12, 19, 68, 56, 43, 23, 25, 39, 66, 42, 16, 47, 51, 
8, 62, 14, 33, 24, 32, 17, 54, 29, 67, 49, 65, 35, 38, 59, 64, 28, 60, 0} 

Using Equation (113), 

1) The basic series of 70 numbers is: { 6, 48, 58, 57, 50, 1, 13, 26, 46, 44, 30, 3, 27, 53, 22, 18, 61, 
7, 55, 36, 45, 37, 52, 15, 40, 2, 20, 4, 34, 31, 10, 5, 41, 9, 69, 63, 21, 11, 12, 19, 68, 56, 43, 23, 
25, 39, 66, 42, 16, 47, 51, 8, 62, 14, 33, 24, 32, 17, 54, 29, 67, 49, 65, 35, 38, 59, 64, 28, 60, 0} 

2) Apply the permutation due to the selection of the subchannel (s), rotate three times: { 57, 50, 1, 
13, 26, 46, 44, 30, 3, 27, 53, 22, 18, 61, 7, 55, 36, 45, 37, 52, 15, 40, 2, 20, 4, 34, 31, 10, 5, 41, 
9, 69, 63, 21, 11, 12, 19, 68, 56, 43, 23, 25, 39, 66, 42, 16, 47, 51, 8, 62, 14, 33, 24, 32, 17, 54, 
29, 67, 49, 65, 35, 38, 59, 64, 28, 60, 0, 6, 48, 58} 

3) Take the first six numbers, add the ULJDcell (perform modulo operation if needed): {59, 52, 
3,15,28,48} 

4) Finally, add the appropriate shift: {59, 122, 143, 225, 308, 398} 
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8.4.6.2.4 Partition a subchannel to mini-subchannels 

An uplink subchannel is composed of six tiles. Mini-subchannels are created by concatenating multiples of 
two, three, or six subchannels, and allocating traffic for more than one SS on this concatenation by a 
subdivision of the tiles. Table 314 shows the four possibilities for subchannel partitioning into mini- 
subchannel. The tile indices are those referred to in Equation (113) for the mandatory uplink permutation, or 
in Equation (1 15) for the optional uplink permutation. 



Table 314 — Subchannel partitioning into mini-subchannels 



Ctype 


Number of 
concatenated 


Number of 
mini- 


Mini- 
subchannel 


Tile allocation as a function subchannel index 
in the concatenation 




subchannels 


subchannels 


index 


0 


1 


2 


3 


4 


5 


00 


2 


2 


0 


0,1,2 


3,4,5 
















1 


3,4,5 


0,1,2 










01 


2 


2 


0 


0,2,4 


0,2,4 
















1 


1,3,5 


1,3,5 










10 


3 


3 


0 


0,1 


2,3 


4,5 














1 


4,5 


0,1 


2,3 














2 


2,3 


4,5 


0,1 








11 


6 


6 


0 


0 


1 


2 


3 


4 


5 








1 


5 


0 


1 


2 


3 


4 








2 


4 


5 


0 


1 


2 


3 








3 


3 


4 


5 


0 


1 


2 








4 


2 


3 


4 


5 


0 


1 








5 


1 


2 


3 


4 


5 


0 



For example, when partitioning to three mini-subchannels, an allocation of n x 3 subchannels is required, 
where n is an integer. Each group of three subchannels in this allocation is partitioned such that the tiles 
indexed 0,1 on the first subchannel; the tiles indexed 2,3 on the second subchannel and the tiles indexed 4,5 
on the third subchannel belong to the mini-subchannel whose index is 0. The tiles indexed 4,5 on the first 
subchannel; the tiles indexed 0,1 on the second subchannel; and the tiles indexed 2,3 on the third subchannel 
belong to the minisubchannel whose index is 1, etc. 

The mini-subchannels are mapped by the UL map like normal subchannels; only the mapping is done by the 
mini-subchannel allocation IE (see 8.4.5.4.8). 
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8.4.6.2.5 Additional optional symbol structure for PUSC 

The additional optional subchannel structure for the uplink supports 96 subchannels where a subchannel 
consists of 48 data carriers and 6 pilot carriers. Each new transmission for the uplink commences with the 
parameters as given in Table 315. 



Table 315— OFDMA uplink subcarrier allocations 



Parameter 


Value 


Number of DC subcarriers 


1 


N used 


1728 


Guard subcarriers: Left, Right 


159, 160 


^subchannels 


96 


N tiles 


576 j 


Number of subcarriers per tile 


3 


Tiles per subchannel 


6 


Number of data subcarriers per subchannel 


48 ! 



8.4.6.2.5.1 Symbol structure for subchannel 

A burst in the uplink is composed of three time symbols and one subchannel, within each burst, there are 48 
data subcarriers and six fixed-location pilot subcarrier. The subchannel is constructed from six uplink tiles, 
each tile has three subcarriers and its configuration is illustrated in Figure 237. 



© © ( Symbol 0 

|| ^ Q Symbol 1 

m m m s y mb ° 12 



pilot carrier Q data carrier 



Figure 237— Description of an uplink tile 
8.4.6.2.5.2 Partitioning of subcarriers into subchannels in the uplink 

To allocate the subchannels, subcarriers are partitioned into tiles which is 3x3 frequency-time block 
containing nine tones (one pilot tones and eight data tones). The whole frequency bands are partitioned into 
groups of contiguous tiles. Each subchannel consists of six tiles, each of which is chosen from different 
groups. 
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For the parameters defined in Table 315, the number of tiles in a group is 32 and there are 18 groups in the 
whole frequency band. Since a subchannel consists of 6 tiles, 6 groups at equal distance (3 groups away 
from each) are chosen and each tile is selected from each group. 

The exact partitioning into subchannels is according to Equation (115), called UL permutation formula. 



Tile{s y m) - 



96 ■ m + 32 • S + [s* + P hCi (m) + P 2y c 2 (m)] 
96-m + 32-S+|y + /Y Ci (m)] 
96-m + 32-5+[y + / ? 2c2 (m)] 
96-m + 32.5 + 5' 



0<c v c 2 <N s 
c { *0,c 2 = 0 
c x = 0, c 2 *0 
Cj = 0, c 2 = 0 



(115) 



where 

Tile(s,m) 
S 

s' 
m 
s 



C2 



is the tile index of m-th tile in subchannel s, 

-l*J- 

= s mod 32, 

is the tile-in-subchannel index from the set [0 ... 5], 

is the index number of a subchannel from the set [0 ... 95], 

is the j-th element of the sequence obtained by rotating basic permutation sequence Pj 
cyclically to the left Cj times. P 7 ={1, 2, 4, 8, 16, 5, 10, 20, 13, 26, 17, 7, 14, 28, 29, 31, 27, 
19, 3, 6, 12, 24, 21, 15, 30, 25, 23, 11, 22, 9, 18}, 

is the j-th element of the sequence obtained by rotating basic permutation sequence P 2 
cyclically to the left c 2 times. P 2 ={ 1, 4, 16, 10, 13, 17, 14, 29, 27, 3, 12, 21, 30, 23, 22, 18, 2, 
8, 5, 20, 26, 7, 28, 31, 19, 6, 24, 15, 25, 11, 9}, 
= IDcell mod 32, 

= I IDcell I 
L 32 J* 



In Equation (115), the operation in [ ] is over GF(2 5 ). In GF(2 5 ), addition is binary XOR operation. For 
example, 29 + 12 in GF(2 5 ) is [(11101) 2 XOR (01100) 2 ] = (10001) 2 = 17, where (x) 2 represents binary 
expansion of x. , 

8.4.6.2.6 Data subchannel rotation scheme 

A rotation scheme shall be applied per each OFDMA slot-duration in any zone, except zones marked as 
AAS zone, or zone using the adjacent- subcarriers permutations (8.4.6.3). Slot-duration is defined in 8.4.3.1. 
On each slot-duration, the rotation scheme shall be applied to all UL subchannels that belong to the segment 
(see 8.4.4.5), except those subchannels indicated in the UL-MAP by UIUC = 13 or UIUC = 12. The rotation 
scheme is defined by applying the following rules: 

1) Per OFDMA slot duration, pick only subchannels that not indicated by either UIUC = 12 or UIUC = 
13 (as defined above). Renumber these subchannels contiguously, such that the lowest numbered 
physical subchannel is renumbered with 0. The total number of subchannels picked shall be 
designated N subchn . 

2) The mapping function defined by item 1) above shall define a function, /, such that 
tempi jsubchannel_number = f(old_subchanneljxumber) 

3) Mark the first UL OFDMA slot-duration with the slot index S idx = 0. Increase S idx by 1 in every slot- 
duration, such that subsequent slots are numbered 1,2,3... etc. 
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4) Apply the formula: 

tempi _subchannel_number = (tempi _subchannel_number + 13*S idx ) mod N subchan 

5) To get the new subchannel number, apply the formula 
new_subchannel_number = f 1 (temp2jsubchannel_number) 
Where/~ 7 (.) is the inverse mapping of the mapping defined in item (2) above. 

6) For subchannels in the UL-MAP indicated by either UIUC=12 or UIUC=13, 
new_subchannel_number - oldjsubchannel_number 

8.4.6.3 Optional permutations for AAS and AMC subchannels 

A BS may change from the "distributed subcarrier permutation," described in 8.4.6.1 and 8.4.6.2, to the 
"adjacent subcarrier permutation" when changing from non-AAS to AAS-enabled traffic to support AAS 
adjacent subcarrier user traffic in the cell. Alternatively, the adjacent subcarrier permutation can be used to 
take advantage of the structure of the adjacent subcarrier permutation in parts of DL subframe that are 
indicated accordingly by the DL-MAP. After this change, the BS shall only transmit/receive traffic using the 
adjacent subcarrier permutation during the allocated period. The BS shall always return to the distributed 
subcarrier permutation at the beginning of a new DL subframe. Note that an AAS-enabled SS, which does 
not provision the same permutation (PUSC/FUSC or adjacent) for AAS traffic selected by the BS for this 
purpose, is not capable of using its AAS capabilities with this BS. 

While the BS does not have any SSs registered that are not capable of using the adjacent subcarrier 
permutation selected by the BS, the BS may employ the AAS superframe structure. Otherwise, it shall 
always return to the distributed subcarrier permutation at the end of each frame and provision broadcast 
traffic at the start of each frame. 

The AAS superframe shall have the following structure: 

1) The BS shall start each superframe with no less than 20 consecutive frames, which contain both 
downlink and uplink broadcast OFDMA symbols. Each of these frames shall provision DCD, 
UCD, DL-MAP, and UL-MAP messages, and at least one initial ranging opportunity. The 
frame duration code in each frame (except the last one) shall be set to the actual frame duration 
used. The frame duration code in the last frame shall be set to 0x00. 

2) Subsequently, the BS shall transmit up to 200 ms of AAS only frames, followed by a minimum 
of one frame containing at least one downlink broadcast OFDMA symbol, which shall 
provision DCD, UCD, and DL-MAP messages. The frame duration code shall be set to 0x00. 

3) The BS shall repeat Step 2) of this subclause, up to the AAS superframe duration, which shall 
be no more than 1 s. 

With the adjacent subcarrier permutation, symbol data within a subchannel is assigned to adjacent 
subcarriers and the pilot and data subcarriers are assigned fixed positions in the frequency domain within an 
OFDMA symbol. This permutation is the same for both uplink and downlink. Within each frame, the BS 
shall indicate the switch to the optional permutation in the AAS_DL_IE() and AAS_ULJE() when 
switching to AAS traffic. (See 8.4.5.3 and 8.4.5.4.) To define adjacent subcarrier permutation, a bin, which 
is the set of nine contiguous subcarriers within an OFDMA symbol, is a basic allocation unit both in 
downlink and uplink. A bin structure is shown in Figure 238. 
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8 data tones 



1 pilot tone 



Figure 238— Bin structure 



A group of four rows of bins is called a band. AMC subchannel consists of six contiguous bins in a same 
band. 



Table 316 — OFDM A AAS subcarrier allocations 



Parameter 


Value 


Number of DC subcarriers 


1 


Number of guard subcarriers, left 


160 


Number of guard subcarriers, right 


159 j 


Nused> Number of used subcarriers (which 
includes the DC subcarrier) 


1729 


Total number of subcarriers 


2048 


Number of pilots 


192 


Number of data subcarriers 


1536 


Number of bands 


48 


Number of bin per band 


4 


Number of data subcarriers per subchannel 


48 



Let the index of the traffic subcarriers be numbered from 0 to 47 within an AMC subchannel. The index of 
first traffic subcarrier in the first bin is 1, next one is 2 and so on. The index of the subcarriers increases 
along the subcarriers first, then the bin. The j-th symbol of the 48 symbols where a band AMC subchannel is 
allocated is mapped onto the (S° p f f r (j) - 1 ) -th subcarrier of a subchannel.; is [0, 47]. 



P per (j) + off*0 

Pper(J) + off=0 



(116) 



Copyright ©2004 IEEE. All rights reserved. 



575 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



where 

p P erii) is the j'fo element of the left cyclic shifted version of basic sequence P 0 by per, 

P 0 Basic sequence defined in GF(7 2 ): {01, 22, 46, 52, 42, 41, 26, 50, 05, 33, 62, 43, 63, 65, 32, 

40, 04, 11, 23, 61, 21, 24, 13, 60, 06, 55, 31, 25, 35, 36, 51, 20, 02, 44, 15, 34, 14, 12, 45, 30, 

03, 66, 54, 16, 56, 53, 64, 10} in hepta-notation, 
per = IDcell mod 48, 

off = (|7Dc«// + 48"|) mod49. 

The addition between two element in GF(7 2 ) is component- wise addition modulo 7 of two representation. 
For example, (56) + (34) in GF(7 2 ) = (13). 

8.4.7 OFDMA ranging 

When used with the WirelessMAN-OFDMA PHY, the MAC layer shall define a single ranging channel 
This ranging channel is composed of one or more groups of six adjacent subchannels, where the groups are 
defined starting from the first subchannel. Optionally, ranging channel can be composed of eight adjacent 
subchannels using the symbol structure defined in 8.4.6.2.5. The indices of the subchannels that compose 
the ranging channel are specified in the UL-MAP message. Users are allowed to collide on this ranging 
channel. To effect a ranging transmission, each user randomly chooses one ranging code from a bank of 
specified binary codes. These codes are then BPSK modulated onto the subcarriers in the ranging channel, 
one bit per subcarrier (subcarriers used for ranging shall be modulated with the waveform specified in 
8.4.7.1/8.4.7.2 and are not restricted to any time grid specified for the data subchannels). 

8.4.7.1 Initial-ranging transmissions 

The initial ranging transmission shall be used by any SS that wants to synchronize to the system channel for 
the first time. An initial-ranging transmission shall be performed during two consecutive symbols. The same 
ranging code is transmitted on the ranging channel during each symbol, with no phase discontinuity between 
the two symbols. A time-domain illustration of the initial-ranging transmission is shown in Figure 239. 
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Figure 239— Initial-ranging transmission for OFDMA 
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The BS can allocate two consecutive initial ranging slots; onto those the SS shall transmit the two 
consecutive initial ranging codes (starting code shall always be a multiple of 2), as illustrated in Figure 240. 
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Figure 240 — Initial-ranging transmission for OFDMA, using two 
consecutive initial ranging codes 

8.4.7.2 Periodic-ranging and bandwidth-request transmissions 

Periodic-ranging transmissions are sent periodically for system periodic ranging. Bandwidth-requests 
transmissions are for requesting uplink allocations from the BS. 

These transmissions shall be sent only by SS that have already synchronized to the system. 

To perform either a periodic-ranging or bandwidth-request transmission, the SS can send a transmission in 
one of the following ways: 

a) Modulate one ranging code on the ranging subchannel for a period of one OFDMA symbol. Ranging 
subchannels are dynamically allocated by the MAC layer and indicated in the UL-MAR A time- 
domain illustration of the periodic-ranging or bandwidth-request transmission is shown in Figure 
241. 



guard 

interval time 




- C 9PY. samples 



OFDM symbol period 

Figure 241— Periodic-ranging or bandwidth-request transmission for 
OFDMA using one code 

b) Modulating three consecutive ranging codes (starting code shall always be a multiple of 3) on the 
ranging subchannel for a period of three OFDMA symbols (one code per symbol). Ranging 
subchannels are dynamically allocated by the MAC layer and indicated in the UL-MAP. A time- 
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domain illustration of the periodic-ranging or bandwidth-request transmission is shown in 
Figure 242. 
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Figure 242— Periodic-ranging or bandwidth-request transmission 
for OFDMA using three consecutive codes 

8.4.7.3 Ranging codes 

The binary codes are the pseudonoise codes produced by the PRBS described in Figure 243, which 
implements the polynomial generator 1 + X l + X 4 + X 7 + x 15 . The PRBS generator shall be initialized by the 
seed bO...M5 = 0,0,l,0,l,0,l,l,s0,sl,s2,s3,s4,s5,s6 where s6 is the MSB, and s6:s0 = ULJDcell. 
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Figure 243— PRBS for ranging code generation 



The binary ranging codes are subsequences of the pseudonoise sequence appearing at its output C k . The 
length of each ranging code is 144 bits. These bits are used to modulate the subcarriers in a group of six 
(eight for the permutation defined in 8.4.6.2.5) adjacent subchannels. The index of the lowest numbered sub- 
channel in the six (eight for the permutation defined in 8.4.6.2.5) shall be an integer multiple of six (eight for 
the permutation defined in 8.4.6.2.5). The six (eight for the permutation defined in 8.4.6.2.5) subchannels 
are called a ranging subchannel. The ranging subchannel is referenced in the ranging and Bandwidth 
Request messages by the index of lowest numbered subchannel. 

For example, the first 144 bit code obtained by clocking the PN generator as specified, with ULJDcell = 0, 
the first code shall be 011110000011111... The next ranging code is produced by taking the output of the 
145th to 288th clock of the PRBS, etc. 
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The number of available codes is 256, numbered 0..255. Each BS uses a subgroup of these codes, where the 
subgroup is defined by a number S, 0 < S < 255. The group of codes will be between 5 and ((S+N+M+L) 
mod 256). 

— The first N codes produced are for initial-ranging. For example, for the default case of two subchan- 
nels in the ranging channel, clock the PRBS 120 x (S mod 256) times to J 20 x ((S + N) mod 256) - / 
times. 

— The next M codes produced are for periodic-ranging. For example, for the default case of two sub- 
channels in the ranging channel, clock the PRBS J 20 x ((N + S) mod 256) times to 120 x ((N + M + 
S) mod 256) -1 times. 

— The next L codes produced are for bandwidth-requests. For example, for the default case of two sub- 
channels in the ranging channel, clock the PRBS 120 x((N + M + S) mod 256) times to 120 x ((N + 
M + L + S) mod 256) -1 times. 

The BS can separate colliding codes and extract timing (ranging) information and power. In the process of 
user code detection, the BS gets the Channel Impulse Response (CIR) of the code, thus acquiring for the BS 
vast information about the user channel and condition. The time (ranging) and power measurements allow 
the system to compensate for the near/far user problems and the propagation delay caused by large cells. 

8.4.8 Transmit diversity (optional) 

8.4.8.1 Transmit diversity using two antennas 

Space-Time Coding (STC) (see Alamouti [Bl]) or frequency hopping diversity coding (FHDC) may be used 
on the downlink to provide second order (Space) transmit diversity. 

There are two transmit antennas on the BS side and one reception antenna on the SS side. This scheme 
requires multiple input single output channel estimation. Decoding is very similar to maximum ratio 
combining. 

Figure 244 shows transmit diversity insertion into the OFDMA chain. Each Tx antenna has its own OFDMA 
chain, but they have the same Local Oscillator for synchronization purposes. 
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Figure 244— Illustration of STC 

Both antennas transmit two different OFDMA data symbols in the same time. Time domain (Space-Time) or 
Frequency domain (Space-Frequency) repetition is used. 
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This mode of operation allows better performance with higher complexity in the receiver. The mode of 
operation introduced in the sequel defines a combined operation of the transmit diversity using PUSC or 
FUSC in the downlink only. The current PUSC mandatory mode of operation allows the splitting of the 
available Subchannels into three segments, each transmitting some (or all) of the subchannels as allocated 
by the FCH. The transmit diversity mode of operation shall be used in a combined way with the mandatory 
mode of operation; this is performed by allocating subchannels to either of the modes of operation. 

The allocation of subchannels to STC operation shall be done by allocating one or more groups of 
subchannels as defined in 8.4.4.4. 

The regular subchannel and preamble transmission in the downlink shall be performed from only one 
antenna (Antenna 0) while the transmit diversity Subchannels transmission shall be performed from both 
antennas obeying the formulas in 8.4.8.1.2.1 and 8.4.8.1.2.1. 

8.4.8.1.1 Multiple input single output channel estimation and synchronization 

Both antennas transmit in the same time and they share the same Local Oscillator. Thus, the received signal 
has exactly the same auto-correlation properties as for a single antenna. Time and frequency coarse and fine 
estimation can be performed in the same way as for a single antenna. The scheme requires multiple input 
single output channel estimation, which is allowed by splitting some pilots between the 2 Tx antennas, as 
described in 8.4.8.1.2.1 and 8.4.8.1.2.1. 

8.4.8.1.2 Space time coding using 2 antennas 
8.4.8.1.2.1 STC encoding 

The basic scheme (Alamouti [Bl]) transmits two complex symbols s x and s 2 , using the multiple input single 
output channel (two Tx, one Rx) with channel vector values h 0 (for antenna 0) and h\ (for antenna 1). 

First channel use: Antenna 0 transmits s\, antennal transmits s 2 . 

Second channel use: Antenna 0 transmits -s 2 * , antennal transmits s { * . 

Receiver gets r 0 (first channel use) and r l (second channel use) and computes sj and s 2 estimates: 



These estimates benefit from second order diversity as in the lTx-2Rx Maximum Ratio Combining scheme. 
The STC transmission may be used both in a PUSC and FUSC configurations. 
8.4.8.1.2.1.1 STC using 2 antennas in PUSC 

In PUSC, the data allocation to cluster is changed (Figure 245) to accommodate two antennas transmission 
with the same estimation capabilities, each cluster shall be transmitted twice from each antenna. 

The clusters composing the subchannels used by the STC mode shall be allocated and subcarriers numbered 
as defined in 8.4.6.2. The cluster structure of the subchannels allocated for STC is slightly modified to fit the 
STC requirements. The structure shall be modified as depicted in Figure 245. (Switching two pilot carriers 
from the odd symbol with two data carriers from the even symbols, and switching of the data carriers and the 
pilots carriers shall be performed after constellation mapping, therefore maintaining all the encoding scheme 



(117) 



(118) 
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and the subchannel allocation scheme.) In this scheme, transmission on regular subchannels and STC sub- 
channels is possible and is determined by the MAC layer (the allocation is performed by allocating major 
groups of subchannels for regular or STC transmission). The transmission of the data shall be performed in 
pairs of symbols as illustrated in Figure 246. 
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Figure 245— Cluster structure 
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Figure 246— STC usage with PUSC 
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8.4.8.1.2.1.2 STC using using 2 antennas in FUSC 

In FUSC, all subchannels shall be used for STC transmission. The pilots within the symbols shall be divided 
between the antennas— antenna 0 uses VariableSet#0 and ConstantSet#0 for even symbols while antenna 1 
uses VariableSet#l and ConstantSet#l for even symbols, antenna 0 uses VariableSet#l and ConstantSet#0 
for odd symbols while antenna 1 uses VariableSet#0 and ConstantSet#l for odd symbols (symbol counting 
starts at the starting point of the relevant STC zone), defined in 8.4.6.1.2.2. The transmission of the data 
shall be performed in pairs of symbols as illustrated in Figure 247. 
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Figure 247— STC usage with FUSC 



8.4.8.1.2.2 STC decoding 

The receiver waits for two symbols, and combines them on a subcarrier basis according to Equation (117) 
and Equation (118) in 8.4.8.1.2.1. 

8.4.8.1.3 Frequency hopping diversity coding (FHDC) 

This scheme (as for STC) transmits two complex symbols, s x and s 2 , using the multiple input single output 
channel (two Tx, one Rx). Allocation of subchannels for FHDC transmission shall be even numbered in the 
same OFDMA symbol, and the first subchannel shall have an even logical index. 

The transmission is based on transmitting the FHDC allocated subchannels from both antennas in the 
following format: 

— Antenna 0 transmits mapped carriers for subchannel X (Sj) onto subchannel X and mapped carriers 
for subchannel X + 1 (S 2 ) onto subchannel X + 1 

— Antenna 1 transmits (-6*2*) onto subchannel X and (Sj *) onto subchannel X + 1 
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Receiver gets r 0 (reception of subchannel X) and r } (reception of subchannel X + 1), and the user shall 
extract signals Sj, S 2 : 



r \ = h x+ 1,0' S 2 + h x+\,l ' S i 



(119) 



These estimates benefit from second order diversity as in the lTx-2Rx Maximum Ratio Combining scheme. 
The downlink preamble will be transmitted for the duration of one OFDMA symbol from both antennas, and 
subchannels used for FHDC are transmitted in adjunct pairs of subchannels. 

The same data/pilot subcarrier structure as defined for the STC mode shall be used in the FHDC mode. 
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Figure 248— Example of using FHDC in PUSC 
8.4.8.1 .4 STC/FHDC configurations 

Two transmission formats are allowed for the two antenna configuration, each format has it own capacity/ 
diversity tradeoffs. The following matrices defines the transmission format with the row index indicating the 
antenna number and column index indicating the subchannel symbol time (two symbols per entry). The 
entries define the transmission from a subchannel used for this transmission configuration (the same 
operation is repeated for all subchannels used in this format). 

Transmission format A uses Matrix A (space time coding rate = 1, as explained in 8.4.8. 1.2 and 8.4.8.1.3): 



A= 5l ~ (52) 
S 2 (5,)* 



(120) 



Transmission format B uses Matrix B (space time coding rate = 2): 
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B = Sx (121) 
8.4.8.1.5 Uplink using STC 

A user-supporting transmission using STC configuration in the uplink, shall use a modified uplink tile, 2- 
transmit diversity data, or 2-transmit spatial multiplexing data that can be mapped onto each subcarrier. The 
mandatory tile shall be modified to accommodate those configurations. Figure 249 depicts the UL title for 
STC transmission. 

Antenna 0 (Pattern A) Antenna 0 (Pattern A) 

O • • • • # # O 

# # O O 0 0 0 0 
###0 O © 0 • 

HI Data subcarrier 
(^ Null subcarrier 
^ Pilot subcarrier 

Figure 249— UL STC tile 



Two single transmit antenna SS's can perform collaborative spatial multiplexing onto the same subcarrier. In 
this case, the one SS should use the uplink tile with pattern-A, and the other SS should use the uplink tile 
withpattern-B. 

8.4.8.1.6 STC of two antennas using directivity through four antennas 

The STC scheme for two antennas may be enhanced by using four antennas at the transmission site. Two 
antennas are now being used in order to transmit each symbol (the first antenna transmits the signal as 
defined in 8.4.8.1.2 and 8.4.8.1.3, and the second transmits the same signal with a complex multiplication 
factor). The BS may change the antenna weights using feedback from the user as described in 8.4.5.4.10.2. 
This scheme is presented in Figure 250. 
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Figure 250 — Illustration of Transmit diversity using four antennas 



This method does not change the channel estimation process of the user; therefore, this scheme could be 
implemented without any changes made to the Transmit diversity user. 

8.4.8.2 Transmit diversity for four antennas 

The Transmit diversity schemes could be further enhanced by using four antennas at the transmission site. 
This configuration could be only used using STC encoding with PUSC or FUSC scheme. 

8.4.8.2.1 STC for four antennas using PUSC 

For this configuration, the basic cluster structure is changed (as indicated in Figure 251) to accommodate the 
transmission from four antennas. (Pilots for antennas 2/3 override data subcarriers in the even symbols. 
Switching and erasing of the data subcarriers shall be performed after constellation mapping; therefore, 
maintaining all the encoding scheme and the subchannel allocation scheme). 
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Figure 251— Cluster structure 



8.4.8.2.2 STC for four antennas using FUSC 

For the FUSC configuration, the pilots embedded within the symbol shall be further divided. The pilots shall 
be transmitted with a structure including four time symbols (repeating itself every four symbols) as follows: 

Symbol 0: antenna 0 uses VariableSet#0 and ConstantSet#0, antenna 1 uses VariableSet#l and Constant- 
Set^ 

Symbol 1: antenna 2 uses VariableSet#0 and ConstantSet#0, antenna 3 uses VariabIeSet#l and Constant- 
Set^ 

Symbol 2: antenna 0 uses VariableSet#l and ConstantSet#0, antenna 1 uses VariableSet#0 and Constant- 
Set^ 

Symbol 3: antenna 2 uses VariableSet#l and ConstantSet#0, antenna 3 uses VariableSet#0 and Constant- 
Set#l 

8.4.8.2.3 STC configurations 

Several transmission formats are allowed for this configuration. Each format has it own capacity/diversity 
tradeoffs. 

The following matrices define the transmission format with the row index indicating the antenna number 
and column index indicating the subchannel symbol time (two symbols per entry). The entries define the 
transmission from a subchannel used for this transmission configuration (the same operation is repeated for 
all subchannels used in this format). 

Transmission format A uses Matrix A (space time coding rate = 1): 



586 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS IEEE Std 802.1 6-2004 



S, -(5 2 ) 0 0 

S 2 (5,)* 0 0 

A = 2 " (122) 

0 0 S 3 -(S 4 )* 

0 0 S 4 (S 3 )* 
Transmission format B uses Matrix B (space time coding rate = 2): 

S, -(S 2 )* S 5 -(5 7 )* 

5 2 (5,)* S 6 -(S„)* 

5 = 2 v " 6 8 ' (123) 

5 3 -(5 4 )* S 7 (S 5 )* 

5 4 (5 3 )* 5 8 (S 6 )* 

Transmission format C uses Matrix C (space time coding rate = 4 ): 

C- * 2 (124) 

^3 

s 4 

8.4.9 Channel coding 

Channel coding procedures include randomization (see 8.4.9.1), FEC encoding (see 8.4.9.2), bit interleaving 
(see 8.4.9.3), and modulation (see 8.4.9.4). When repetition code is used, allocation for the transmission 
shall always include an even number of adjacent subchannels. The basic block shall pass the regular coding 
chain where the first subchannel shall set the randomization seed used in 8.4.9.1, and the data shall follow 
the coding chain up to the mapping. The data outputted from the modulation (8.4.9.4) shall be mapped onto 
the block of subchannels allocated for the basic block and then it will be also mapped on the following 
consecutive allocated subchannels (for repetition coding of 2, another block of subchannels of the same size 
is used; for repetition coding of 4, another 3 blocks of subchannels of the same size are used; and for 
repetition of 6, another 5 blocks of subchannels of the same size are used), the process of regular encoding 
and repetition encoding is shown in Figure 252. 
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Figure 252— Channel coding process for regular and repetition coding transmission 
8.4.9.1 Randomization 

Data randomization is performed on data transmitted on the downlink and uplink. The randomization is 
initialized on each FEC block (using the first Subchannel offset and OFDM A symbol offset on which the 
FEC block is mapped. Symbol offset, for both UL and DL, shall be counted from the start of the frame, 
where the DL preamble shall be count 0). If the amount of data to transmit does not fit exactly the amount of 
data allocated, padding of OxFF ("1" only) shall be added to the end of the transmission block, up to the 
amount of data allocated. 

The PRBS generator shall be 1 +x 14 + x 15 , as shown in Figure 253. Each data byte to be transmitted shall 
enter sequentially into the randomizer, MSB first. Preambles are not randomized. The seed value shall be 
used to calculate the randomization bits, which are combined in an XOR operation with the serialized bit 
stream of each FEC block. The randomizer sequence is applied only to information bits. 



MSB 



LSB 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 



<3 



i in 




Figure 253— PRBS for data randomization 
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The bit issued from the randomizer shall be applied to the encoder. 

The randomizer is initialized with the vector created as shown in Figure 254. 



OFDMA Symbol Offset (10 LSB) 



Subchannel Offset (5 LSB) 



b 9 


h 


h 


h 




h 


h 










MSB 




f> 14 


^13 


b l2 






h 


h 


h 


h 




b A 


h 


h 


h 





LSB 



OFDMA randomizer initialization vector 
Figure 254 — Creation of OFDMA randomizer initialization vector 



8.4.9.2 Encoding 

The coding method used as the mandatory scheme will be the tail-biting convolutional encoding specified in 
8.4.9.2.1, and the optional modes of encoding in 8.4.9.2.2 and 8.4.9.2.3 shall be also supported. 

The encoding block size shall depend on the number of subchannels allocated and the modulation specified 
for the current transmission. 

Concatenation of a number of subchannels shall be performed in order to make larger blocks of coding 
where it is possible, with the limitation of not passing the largest block under the same coding rate (the block 
defined by 64-QAM modulation). Table 318 specifies the concatenation of subchannels for different 
allocations and modulations. The parameters in Table 317 and Table 318 shall apply to the CC encoding 
scheme (see 8.4.9.2.1) and the BTC encoding scheme (see 8.4.9.2.2); for the CTC encoding scheme (see 
8.4.9.2.3), the concatenation rule is defined in 8.4.9.2.3.3. 

For any modulation and FEC rate, given an allocation of n subchannels, the following parameters are 
defined: 



— j: parameter dependent on the modulation and FEC rate 

— n: number of allocated subchannels 

— k: floor (n/j) 

— m: n modulo j 

Table 317 shows the rules used for subchannel concatenation. 



Table 317— Subchannel concatenation rule 



Number of 
subchannels 


Subchannels concatenated 


n<j 


1 block of n subchannels 


n>j 


(k-I) blocks of j subchannels 

1 block of ceil((m+/)/2) subchannels 

1 block of floor((m+/')/2) subchannels 
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Table 318 — Encoding Subchannel concatenation for different allocations and modulations 



Modulation 
and rate 


j 


QPSK 1/2 


7 = 6 


QPSK 3/4 


; = 4 


16-QAM 1/2 


7 = 3 


16-QAM 3/4 


7 = 2 


64-QAM 1/2 


7 = 2 


64-QAM 2/3 


7=1 


64-QAM 3/4 





8.4.9.2.1 Convolutional coding (CC) 

Each FEC block is encoded by the binary convolutional encoder, which shall have native rate of 1/2, a 
constraint length equal to K = 7, and shall use the following generator polynomials codes to derive its two 
code bits: 



171 



OCT 



FOR X 
FOR Y 



(125) 



The generator is depicted in Figure 255. 



^ X output 



Data in 




- Y output 



Figure 255 — Convolutional encoder of rate 1/2 
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The puncturing patterns and serialization order that shall be used to realize different code rates are defined in 
Table 319. In the table, "1" means a transmitted bit and "0" denotes a removed bit, whereas X and Y are in 
reference to Figure 255. 



Table 319 — The inner convolutional code with puncturing configuration 





Code Rates 


Rate 


1/2 


2/3 


3/4 


5/6 


d free 


10 


6 


5 


4 


X 


1 


10 


101 


10101 


Y 


1 


11 


110 


11010 


XY 


X X Y X 


X X Y X Y 2 




X\YiY 2 X 3 Y 4 X 5 



Each FEC block is encoded by a tail-biting convolutional encoder, which is achieved by initializing the 
encoders memory with the last data bits of the FEC block being encoded (the packet data bits numbered b n 

Table 320 defines the basic sizes of the useful data payloads to be encoded in relation with the selected 
modulation type and encoding rate and concatenation rule. 



Table 320— Useful data payload for a subchannel 





QPSK 


16 QAM 


64 QAM 


Encoding rate 


R=l/2 


R=3/4 


R=l/2 


R=3/4 


R=l/2 


R=2/3 


R=3/4 


Data payload 
(bytes) 


6 
















9 














12 




12 












18 


18 




18 


18 








24 




24 






24 








27 










27 j 




30 
















36 


36 


36 


36 


36 







8.4.9.2.2 Block Turbo Coding (optional) 

The BTC is based on the product of two simple component codes, which are binary extended Hamming 
codes or parity check codes from the set depicted in Table 321. 
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Table 321 specifies the generator polynomials for the Hamming codes. To create extended Hamming codes, 
an overall even parity check bit is added at the end of each code word. 



Table 321— OFDMA Hamming code generator polynomials 





k> 


Generator polynomial 


. 15 


11 




31 


26 


X 5 +X 2 +l 


63 


57 


^+x+l 



The component codes are used in a two-dimensional matrix form, which is depicted in Figure 256. The k x 
information bits in the rows are encoded into n x bits by using the component block (n x , k x ) code specified for 
the respective composite code. After encoding the rows, the columns are encoded using a block code (n y k y ), 
where the check bits of the first code are also encoded. The overall block size of such a product code is 
n = n x xriy, the total number of information bits k = k x x ky and the code rate is R = R x x R yi where /?,• = k jn v 
i = jc, y. The Hamming distance of the product code is d = d x x dy. Data bit ordering for the composite BTC 
matrix is the first bit in the first row is the LSB and the last data bit in the last data row is the MSB. 

Transmission of the block over the channel shall occur in a linear fashion, with all bits of the first row 
transmitted left to right followed by the second row, etc. 

To match a required packet size, BTCs may be shortened by removing symbols from the BTC array. In the 
two-dimensional case, rows, columns, or parts thereof can be removed until the appropriate size is reached. 
There are three steps in the process of shortening product codes: 

Step 1) Remove I x rows and I y columns from the two-dimensional code. This is equivalent to 
shortening the constituent codes that make up the product code. 

Step 2) Remove B individual bits from the first row of the two-dimensional code starting with 
the LSB. 

Step 3) Use if the product code specified from Step 1) and Step 2) of this subclause has a non- 
integral number of data bytes. In this case, the Q leftover LSB are zero-filled by the 
encoder. After decoding at the receive end, the decoder shall strip off these unused bits 
and only the specified data payload is passed to the next higher level in the PHY. The 
same general method is used for shortening the last code word in a message where the 
available data bytes do not fill the available data bytes in a code block. 

These three processes of code shortening are depicted in Figure 256. In the first two-dimensional BTC, a 
nonshortened product code is shown. By comparison, a shortened BTC is shown in the adjacent two- 
dimensional array. The new coded block length of the code is (n x - I x )(n y - I y ) - B. The corresponding 
information length is given as (k x - I x )(k y - l y ) - B - Q. Consequently, the code rate is given by 
Equation (126). 

{ k x -l x )(k y -l y )-B-Q 

(n x -l x )(n y -l y )-B > 
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Checks 


Checks 


Checks 

on 
Checks 



ky 



B Q 
Information Bits 



Checks 



Checks 



Checks 

on 
Checks 



Figure 256 — BTC and shortened BTC structure 



Table 322 gives the block sizes for the optional modulation and coding schemes using BTC. Table 323 gives 
the code parameters for each of the possible data and coded block sizes. 



Table 322— Useful data payload for a subchannel 





QPSK 


16-QAM 


64-QAM 


Coded 
Bytes 


Encoding 
Rate 


R=l/2 


R=3/4 


R=l/2 


R=3/4 


R=l/2 


R=3/4 


Allowed 

Data 

(Bytes) 


6 


9 










12 


16 


20 


16 


20 






24 


16 


25 






16 


25 


36 


23 


35 


23 


35 






48 ! 


31 












60 


40 




40 




40 




72 | 



Table 323— Optional channel coding per modulation 



Data 
Bytes 


Coded 
Bytes 


Constituent 


Code 
parameters 


6 


12 


(8,7)(32,26) 


7^=4, 7^=8, B=0, Q=6 


9 


12 


(16,15)(16,15) 


7^6, 7^=6, B=4, Q=5 


16 


24 


(8,7)(32,26) 


7^2, 7^=0, B=0, Q=2 


20 


24 


(16,15)(16,15) 


7^=2,7^2, B=4, Q=5 


16 


36 


(32,26X16,11) 


7^11,7^=2, B=6,Q=7 
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Table 323 — Optional channel coding per modulation (continued) 



Data 
Bytes 


Coded 
Bytes 


Constituent 


Code 
parameters 


25 


36 


(8,7)(64,57) 


7^2,7^=16, B=0, Q=5 


23 


48 


(32,26)(16,11) 


7^4, 7^=2, B=8, Q=6 


35 


48 


(32,26)(16,15) 


7^0, 7y=4, B=0, Q=6 


31 


60 


(32,26X32,26) 


7-^10,7^=10, B=4, Q=4 


40 


72 


(32,26)(32,26) 


J>8, / v =8, B=0, Q=4 



8.4.9.2.3 Convolutional turbo codes (optional) 
8.4.9.2.3.1 CTC encoder 

The Convolutional Turbo Code (CTC) defined in this subclause is designed to enable support of hybrid 
ARQ (HARQ). HARQ implementation is optional. The CTC encoder, including its constituent encoder, is 
depicted in Figure 257. It uses a double binary Circular Recursive Systematic Convolutional code. The bits 
of the data to be encoded are alternately fed to A and B, starting with the MSB of the first byte being fed to 
A. The encoder is fed by blocks of k bits or N couples (k = 2*N bits). For all the frame sizes, A: is a multiple 
of 8 and Wis a multiple of 4. Further, N shall be limited to: 8 < N/4 < 1024 . 

The polynomials defining the connections are described in octal and symbol notations as follows: 

— For the feedback branch: OxB, equivalently 1 + D + D 3 (in symbolic notation) 

— For the Y parity bit: OxD, equivalently 1 + D 2 + D 3 

— For the W parity bit: 0x9, equivalently 1 + D 3 
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Systematic part 



A 
B 



Constituent encoder 
Figure 257 — CTC encoder 



Parity part 



First, the encoder (after initialization by the circulation state Sc\, see 8.4.9.2.3.3) is fed the sequence in the 
natural order (position 1) with the incremental address i = 0 .. N-l. This first encoding is called Q encoding. 
Then the encoder (after initialization by the circulation state Sc 2 , see 8.4.9.2.3.3) is fed by the interleaved 
sequence (switch in position 2) with incremental address j = 0, ... N-l. This second encoding is called C 2 
encoding. 

The order in which the encoded bit shall be fed into the subpacket generation block (8.4.9.2.3.4) is: 

A, B, Y h Y 2 , W It W 2 = 

A 0> B 0>— > A N-1> B N-1> Y l,0 Y 1,N-1> Y 2,0 Y 2,l>—> Y 2,N-1> W l,0> W lJ>—> W l f N-l> W 2,0 W 2,l>—> W 2,N-1 

Note that the interleaver (8.4.9.3) shall not be used when using CTC. 

The encoding block size shall depend on the number of subchannels allocated and the modulation specified 
for the current transmission. Concatenation of a number of subchannels shall be performed in order to make 
larger blocks of coding where it is possible, with the limitation of not passing the largest block under the 
same coding rate (the block defined by 64-QAM modulation). Table 325 specifies the concatenation of sub- 
channels for different allocations and modulations. The concatenation rule shall not be used when using 
H-ARQ. 

For any modulation and FEC rate, given an allocation of n subchannels, the following parameters are 
defined: 

j parameter dependent on the modulation and FEC rate 

n number of allocated subchannels 

k = f\oor(n/j) 

m ~ n mod j 
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Table 324 shows the rules used for subchannel concatenation: 



Table 324— Subchannel concatenation rule for CTC 



Number of subchannels 


Subchannels concatenated 


n<j 


1 block of n subchannels 


n = l 


1 block of 4 subchannels 
1 block of 3 subchannels 


n>j 


(k-1) blocks of j subchannels 
1 block of L bl subchannels 
1 block of L b2 subchannels 

Where: 

L w =ceil((m+/)/2) \ 
L b2 = floor((m+/')/2) 

If(L w = 7)or(L M = 7) 

Lbl = Lbl + 1; Lbl = Lb2 - 1; 



Table 325— Encoding subchannel concatenation for different rates in CTC 



Modulation and rate 


j 


QPSK 1/2 


10 


QPSK 3/4 


6 


16-QAM 1/2 


5 


16-QAM 3/4 


3 


64-QAM 1/2 


3 


64-QAM 2/3 


2 


64-QAM 3/4 


2 


64-QAM 5/6 


2 
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Table 326 gives the block sizes, code rates, channel efficiency, and code parameters for the different modu- 
lation and coding schemes. As 64-QAM is optional, the codes for this modulation shall only be implemented 
if the modulation is implemented. Table 327 shows code parameters for HARQ. 



Table 326— Optimal CTC channel coding per modulation 



Modulation 


Data 
block size 
(bytes) 


Encoded 
data block 
size (bytes) 


Code 
rate 




p o 


n 
P l 


n 




QPSK 


6 


12 


1/2 


24 


5 


0 


0 


0 


QPSK 


12 


24 


1/2 


48 


13 


24 


0 


24 


QPSK 


18 


36 


1/2 


72 


11 


6 


0 


6 


QPSK 


24 


48 


1/2 


96 


7 


48 


24 


72 1 


QPSK 


30 ' 


60 


1/2 


120 


13 


60 


0 


60 


QPSK 


36 


72 


1/2 


144 


17 


74 


72 


2 


QPSK 


48 


96 


1/2 


192 


11 


96 


48 


144 j 


QPSK 


54 


108 


1/2 


216 


13 


108 


0 


108 


QPSK 


60 


120 


1/2 


240 


13 


120 


60 


180 


QPSK 


9 


12 


3/4 


36 


11 


18 


0 


18 


QPSK 


18 


24 


3/4 


72 


11 


6 


0 


6 


QPSK 


27 


36 


3/4 


108 


11 


54 


56 


2 • 


QPSK 


36 


48 


3/4 


144 


17 


74 


72 


2 


QPSK 


45 


60 


3/4 


180 


11 


90 


0 


90 


QPSK 


54 


72 


3/4 


216 


13 


108 


0 


108 


16-QAM 


12 


24 


1/2 


48 


13 


24 


0 


24 


16-QAM 


24 


48 


1/2 


96 


7 


48 


24 


72 


16-QAM 


36 


72 


1/2 


144 


17 


74 


72 


2 


16-QAM 


48 


96 


1/2 


192 


11 


96 


48 


144 


16-QAM 


60 


120 


1/2 


240 


13 


120 


60 


180 


16-QAM 


18 


24 


3/4 


72 


11 


6 


0 


6 j 


16-QAM 


36 


48 


3/4 


144 


17 


74 


72 


2 


16-QAM 


54 


108 


3/4 


216 


13 


108 


0 


108 


64-QAM 


18 


24 


1/2 


72 


11 


6 


0 


6 


64-QAM 


36 


72 


1/2 


144 


17 


74 


72 


2 


64-QAM 


54 


108 


1/2 


216 


13 


108 


0 


108 


64-QAM 


24 


36 


2/3 


96 


7 


48 


24 


72 


64-QAM 


48 


72 


2/3 


192 


11 


96 


48 


144 


64-QAM 


27 


36 


3/4 


108 


11 


54 


56 


2 
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Table 326— Optimal CTC channel coding per modulation (continued) 



Modulation 


Data 
block size 
(bytes) 


Encoded 
data block 
size (bytes) 


Code 
rate 


N 


Po 


Pi 


P 2 


P 3 


64-QAM 


54 


72 


3/4 


216 


13 


108 


0 


108 


64-QAM 


30 


36 


5/6 


120 


13 


60 


0 


60 


64-QAM 


60 


72 


5/6 


240 


13 


120 


60 


180 



Table 327— Optimal CTC channel coding per modulation when supporting H-ARQ 



Data 
block size 
(bytes) 


N 


P0 


PI 


P2 


P3 


6 


24 


5 


0 


0 


0 


12 


48 


13 


24 


0 


24 


18 


72 


11 


6 


0 


6 


24 


96 


7 


48 


24 


72 


36 


144 


17 


74 


72 


2 • 


48 


192 


11 


96 


48 


144 


60 


240 


13 


120 


60 


180 


120 


480 


13 


240 


120 


360 


240 


960 


13 


480 


240 


720 


360 


1440 


17 


720 


360 


540 


480 


1920 


17 


960 


480 


1440 


600 


2400 


17 


1200 


600 


1800 



8.4.9.2.3.2 CTC inter leaver 

The interleaver requires the parameters P 0 and P h shown in Table 326. 
The two-step interleaver shall be performed by: 

Step 1: Switch alternate couples 

for j = 0..JV-1 

if ( j modj ==0) let (BA) = (A,B) (i.e., switch the couple) 
Step 2: Pi(j) 

The function P t {j) provides the interleaved address i of the consider couple j. 
for j = 0..JV-1 

switch ; m0 d 4 : 

caseO: i = (P 0 •>+ i) modjv 
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easel: i = {P 0 j + \ +N/2 + P l ) mo6N 
case 2: / = (P 0 j + 1 + /> 2 ) mod , 
case3:i = (P 0 .y + l + yv/2 + /> 3 ) modjtf 

8.4.9.2.3.3 Determination of CTC circulation states 

The state of the encoder is denoted 5 (0 < S < 7) with S the value read binary (left to right) out of the 
constituent encoder memory (see Figure 257). The circulation states Sc\ and Sc 2 are determined by the 
following operations: 

1) Initialize the encoder with state 0. Encode the sequence in the natural order for the 
determination of Sc { or in the interleaved order for determination of Sc 2 . In both cases the final 
state of the encoder is S0 N _\; 

2) According to the length N of the sequence, use Table 328 to find Sc { or 5c 2 . 



Table 328 — Circulation state lookup table (Sc) 



^mod 7 




0 


1 


2 


3 


4 


5 


6 


7 


1 


0 


6 


4 


2 


7 


1 


3 


5 


2 


0 


3 


7 


4 


5 


6 


2 


1 


3 


0 


5 


3 


6 


2 


7 


1 


4 ! 


4 


0 


4 


1 


5 


6 


2 


7 


3 


5 


0 


2 


5 


7 


1 


3 


4 


6 


6 


0 


7 


6 


1 


3 


4 


5 


2 



8.4.9.2.3.4 Subpacket generation 

Proposed FEC structure punctures the mother codeword to generate a subpacket with various coding rates. 
The subpacket is also used as HARQ packet transmission. Figure 258 shows a block diagram of subpacket 
generation. 1/3 CTC encoded codeword goes through interleaving block and the puncturing is performed. 
Figure 259 shows block diagram of the interleaving block. The puncturing is performed to select the 
consecutive interleaved bit sequence that starts at any point of whole codeword. For the first transmission, 
the subpacket is generated to select the consecutive interleaved bit sequence that starts from the first bit of 
the systematic part of the mother codeword. The length of the subpacket is chosen according to the needed 
coding rate reflecting the channel condition. The first subpacket can also be used as a codeword with the 
needed coding rate for a burst where HARQ is not applied. 
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Figure 258— Block diagram of subpacket generation 
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Figure 259— Block diagram of the interleaving scheme 
8.4.9.2.3.4.1 Symbol separation 

All of the encoded symbols shall be demultiplexed into six subblocks denoted A, B, Y h Y 2 , Wj, and W 2 . The 
encoder output symbols shall be sequentially distributed into six subblocks with the first, encoder output 
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symbols going to the A subblock, the second encoder output going to the B subblock, the third to the Yj sub- 
block, the fourth to the Y 2 subblock, the fifth to the Wj subblock, the sixth to the W 2 subblock, etc. 

8.4.9.2.3.4.2 Subblock interleaving 

The six subblocks shall be interleaved separately. The interleaving is performed by the unit of symbol. The 
sequence of interleaver output symbols for each subblock shall be generated by the procedure described 
below. The entire subblock of symbols to be interleaved is written into an array at addresses from 0 to the 
number of the symbols minus one (N-J), and the interleaved symbols are read out in a permuted order with 
the i-th symbol being read from an address, AD ( ( i = 0... N-l ), as follows: 

3. Determine the subblock interleaver parameters, m and J . Table 329 gives these parameters. 

4. Initialize i and k to 0. 

5. Form a tentative output address T k according to the formula: 
T k = 2 m (k mod J) + BRO m {lk/J\) 

where BRO m (y) indicates the bit-reversed m-bit value of y (i.e., BR03(6) = 3). 

6. If T k is less than N ADi = T k and increment i and k by 1 . Otherwise, discard T k and increment k only. 

7. Repeat steps 3) and 4) until all Af interleaver output addresses are obtained. 

The parameters for the subblock interleavers are specified in Table 329. 



Table 329— Parameters for the subblock interleavers 



Block size 
(bits) 
#EP 


N 


Subblock interleaver 
parameters 


m 


J 


48 


24 


3 


3 \ 


72 


36 


4 


3 


96 


48 


4 


3 


144 


72 


5 


3 


192 


96 


5 


3 


216 


108 


6 


3 


240 


120 


6 


2 


288 


144 


6 


3 


384 


192 


6 


3 


432 


216 


6 


4 


480 


240 


7 


2 
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Table 330— Parameters for the subblock interleavers when supporting H-ARQ 



Rlflf*lf 

(bits) 

^EP 


N 


Subblock interleaver 
parameters 


m 


/ 


48 


24 


3 


3 


96 


48 


4 


3 


144. 


72 


5 


3 


192 


96 


5 


3 


288 


144 


6 


3 


384 


192 


6 


3 


480 


240 


7 


2 


960 


480 


8 


2 


1920 


960 


9 


2 


2880 


1440 


9 


3 


3840 


1920 


10 


2 


4800 


2400 


10 


3 



8.4.9.2.3.4.3 Symbol grouping 

The channel interleaver output sequence shall consist of the interleaved A and B subblock sequence, 
followed by a symbol-by-symbol multiplexed sequence of the interleaved Yj and Y 2 subblock sequences, 
followed by a symbol-by-symbol multiplexed sequence of the interleaved Wj and W 2 subblock sequences. 
The symbol-by- symbol multiplexed sequence of interleaved Y 1 and Y 2 subblock sequences shall consist of 
the first output bit from the Yj subblock interleaver, the first output bit from the Y 2 subblock interleaver, the 
second output bit from the Yj subblock interleaver, the second output bit from the Y 2 subblock interleaver, 
etc. The symbol-by-symbol multiplexed sequence of interleaved W } and W 2 subblock sequences shall 
consist of the first output bit from the W 2 subblock interleaver, the first output bit from the W 2 subblock 
interleaver, the second output bit from the Wj subblock interleaver, the second output bit from the W 2 
subblock interleaver, etc. Figure 259 shows the interleaving scheme. 

8.4.9.2.3.4.4 Symbol selection 

Lastly, symbol selection is performed to generate the subpacket. The puncturing block is referred as symbols 
selection in the viewpoint of subpacket generation. 

Mother code is transmitted with one of subpackets. The symbols in a subpacket are formed by selecting 
specific sequences of symbols from the interleaved CTC encoder output sequence. The resulting subpacket 
sequence is a binary sequence of symbols for the modulator. 

Let 

k be the subpacket index when HARQ is enabled, k - 0 for the first transmission and increases by 

one for the next subpacket. k = 0 when H-ARQ is not used. 
N EP be the number of bits in the encoder packet (before encoding). 
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NsCHk be the number of subchannel(s) allocated for the Jt-th subpacket. 

m k be the modulation order for the £-th subpacket {m k = 2 for QPSK, 4 for 16-QAM, and 6 for 64- 
QAM). 

SPlD k be the subpacket ID for the &-th subpacket, (for the first subpacket, SPID k=0 = 0). 

Also, let the scrambled and selected symbols be numbered from zero with the 0-th symbol being the first 
symbol in the sequence. Then, the index of the z-th symbol for the fc-th subpacket shall be: 

hi = (F t + i)mod(3'N EP ) (127) 

where: 

i = 0...L k -l, 

L k = 4S'N SCHk -m k , 

F k = (SPID k • L k )mod(3 - N EP ) . 

The N EP , N SCHh m k , and SPID values are determined by the BS and can be inferred by the SS through the 
allocation size in the DL-MAP and UL-MAP. The above symbol selection makes the following possible. 

1) The first transmission includes the systematic part of the mother code. Thus, it can be used as the 
codeword for a burst where the HARQ is not applied. 

2) The location of the subpacket can be determined by the SPID itself without the knowledge of 
previous subpacket. It is very important property for HARQ retransmission. 

8.4.9.2.3.5 Optional H-ARQ Support 

H-ARQ implementation is optional. The randomization block in 8.4.9.1, the concatenation scheme in 
8.4.9.2.3.1, and the interleaving in 8.4.9.3 shall not be applied for the encoding described in this subclause. 

8.4.9.2.3.5.1 Padding 

MAC PDU (or concatenated MAC PDUs) is a basic unit processed in this channel coding and modulation 
blocks. When the size of MAC PDU (or concatenated MAC PDUs) is not the element in the allowed set for 
H-ARQ, ' 1 's are padded at the end of MAC PDU (or concatenated MAC PDUs). The amount of the padding 
is the same as the difference between the size of the PDU (or concatenated MAC PDUs) and the smallest 
element in the allowed set that is not less than the size of the PDU (or concatenated MAC PDUs). The 
padded packet is input into the randomization block. 

The allowed set is {32, 80, 128, 176, 272, 368, 464, 944, 1904, 2864, 3824, 4784, 9584, 14384, 19184, 
23984} bits. 

8.4.9.2.3.5.2 Randomization 

The randomization is performed on each allocation (burst), which means that for each allocation of a data 
block the randomizer shall be used independently. 

The PRBS generator shall be l +x !4 + x 15 as shown in Figure 260. Each data byte to be transmitted shall 
enter sequentially into the randomizer, MSB first. Preambles are not randomized. The seed value shall be 
used to calculate the randomization bits, which are combined in an XOR operation with the serialized bit 
stream of each FEC block. The randomizer sequence is applied to the output from the padding block. The bit 
issued from the randomizer shall be applied to the CRC encoder. 
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MSB 



LSB 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 




data in 




Figure 260— PRBS of the randomization 

The bit issued from the randomizer shall be applied to the encoder. 

The scrambler is initialized with the vector created as shown in Figure 261. The lowest 5 bits are IDcell or 
ULJDcell and the other bits are set "0." 

IDcell (5 LSB) 



0 


0 


0 


0 


0 


0 


0 


0 


0 


0 





b 4 


h 


h 


h 






MSB 






b l3 


b n 


bu 


b\o 


b 9 


b, 


b, 


b 6 


b 5 


b A 




b 2 


h 


b 0 



LSB 



OFDMA randomizer initialization vector 
Figure 261— Initialization construction for the PRBS of the randomizer 



8.4.9.2.3.5.3 CRC encoding 

When H-ARQ is applied to a packet, error detection is provided on the padded packet through a Cyclic 
Redundancy Check (CRC). 

The size of the CRC is 16 bits. CRC16-CCITT, as defined in ITU-T Recommendation X.25, shall be 
included at the end of the padded and randomized packet. The CRC covers both the padded bits and the 
information part of the padded and randomized packet. After the CRC operation, The packet size shall 
belong to set {48, 96, 144, 192, 288, 384, 480, 960, 1920, 2880, 3840, 4800, 9600, 14400, 19200, 24000}. 

8.4.9.2.3.5.4 Fragmentation 

When the size after the padding and CRC encoding is n*4800 bits they are separately encoded by the block 
of 4800 bits and concatenated as the same order of the separation before modulation. No operation is 
performed for the packet whose size after the padding and CRC encoding is not more than 4800 bits. The 
bits output from the fragmentation block are denoted by r v r 2 , r^, and this sequence is defined as 
encoder packet. N EP is the number of the bits in an encoder packet and defined as encoder packet size. The 
values of N EP aiG 48, 96, 144, 192, 288, 384, 480, 960, 1920, 2880, 3840, 4800. 
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8.4.9.2.3.5.5 CTC encoding and subpacket generation 

The CTC encoding and subpacket generation is the same as the operation described in 8.4.9.2.3.1, 
8.4.9.2.3.2, 8.4.9.2.3.3, and 8.4.9.2.3.4. 



8.4.9.2.3.5.6 Modulation order of DL traffic burst 



For DL, the modulation order (2 for QPSK, 4 for 16-QAM, and 6 for 64-QAM) shall be set for all the 
allowed transmission formats as shown in Table 331. The transmission format is given by the N EP 
(Encoding Packet Size) and the N SCH (number of allotted subchannels). N EP per an encoding packet is { 144, 
192, 288, 384, 480, 960, 1920, 2880, 3840, 4800}. The N SCfi per an encoding packet is {1, 480}. In Table 
331, the numbers in the first row are N EP s and the numbers in the remaining rows are N SCH 's and related 
parameters. 

The supportable modulation schemes are QPSK, 16-QAM, and 64-QAM. When the N EP and the N SCH are 
given, the modulation order is determined by the value of MPR (Modulation order Product code Rate). The 
MPR means the effective number of the information bit transmitted per a subcarrier and is defined by 
Equation (128). 

= 5rfe (128 > 

Then, the modulation order is specified by the following rule: 
If 0 < MPR < 1.5 , then a QPSK (modulation order 2) is used 
If 1.5 < MPR < 3.0 , then a 16QAM (modulation order 4) is used 
If 3.0 < MPR < 5.4 , then a 64QAM (modulation order 6) is used 



The effective code rate is equal to MPR divided by the modulation order (i.e., 2 for QPSK). 

The information of N EP and N SCH shall be signaled in UL MAP. Instead of the actual values of N EP and 
N SCH> tne encoded value of N EP (N EP code) and N SCH (N SCH code) shall be used for the signaling. They are 
encoded by 4 bits, respectively. The encoding of N EP (N EP code) is shown in Table 332. The encoding of 
N SCH ( Nscn code ) is performed per N EP value. For each N EP > there are less than 16 kinds ofN SCH values and 
they are encoded from "0"(the smallest number of subchannels) to "15" in increasing order. When the 
number of N SCH values for a N EP is smaller than 16, the smallest number of the smallest codes are used. 
When the fragmentation is applied and the number of the subpackets for an allocation is n, n*N EP and N SCH 
(the number of subchannels allocated for a subpacket) should be signaled. 

The encoding for n*N EP (N EP code) is also shown in Table 332. The encoded value of N SCH (N SCH code) 
should be interpreted as N SCH . for a subpacket, and n*N SCH for the whole allocation. 
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Table 331— Transmission format and modulation level for DL 



Nf P 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 


1.00 


1.00 


















MPR 


3.00 


4.00 


















MOD 


6.00 


6.00 


















Rate 


1/2 


2/3 


















Kaie 




0 fH 
v.u / 


















Sch 


2.00 


2.00 


2.00 


2.00 


2.00 












MPR 


1.50 


2.00 


3.00 


4.00 


5.00 












MOD 


4.00 


4.00 


6.00 


6.00 


6.00 












Rate 


3/8 


1/2 


1/2 


2/3 


5/6 












Kaie 


n ir 


0 so 


0.50 


0.67 


0.83 












Sch 


3.00 


3.00 


3.00 


3.00 


3.00 












MPR 


1.00 


1.33 


2.00 


2.67 


3.33 












MOD 


2.00 


2.00 


4.00 


4.00 


6.00 












Rate 


1/2 


2/3 


1/2 


2/3 


5/9 












Rate 


U.3U 


yj.\j / 


0 so 

u.JU 


0.67 


0.56 












Sch 




4.00 


4.00 


4.00 


4.00 


4.00 










MPR 




1.00 


1.50 


2.00 


2.50 


5.00 










MOD 




2.00 


4.00 


4.00 


4.00 


6.00 










Rate 




1/2 


3/8 


1/2 


5/8 


5/6 










Rate 






0 18 


0 so 


0.63 


0.83 










Sch 


5.00 




5.00 


5.00 


5.00 


5.00 










MPR 


0.60 




1.20 


1.60 


2.00 


4.00 










MOD 


2.00 




2.00 


4.00 


4.00 


6.00 










Rate 


3/10 




3/5 


2/5 


1/2 


2/3 










Rate 


n in 




0.60 


0.40 


0.50 


0.67 










Sch 


6.00 


6.00 


6.00 


6.00 


6.00 


6.00 










MPR 


0.50 


0.67 


1.00 


1.33 


1.67 


3.33 










MOD 


2.00 


2.00 


2.00 


2.00 


4.00 


6.00 










Rate 


1/4 


1/3 


1/2 


2/3 


5/12 


5/9 










Rate 


U.Zj 


n 11 


o so 

\J.J\J 




0.42 


0.56 










Sch 




8.00 




8.00 


8.00 


8.00 


8.00 








MPR 




0.50 




1.00 


1.25 


2.50 


5.00 








MOD 




2.00 




2.00 


2.00 


4.00 


6.00 








Rate 




1/4 




1/2 


5/8 


5/8 


5/6 








Rate 




0.25 




0.50 


0.63 


0.63 


0.83 








Sch 


9.00 




9.00 








9.00 








MPR 


0.33 




0.67 








4.44 








MOD 


2.00 




2.00 








6.00 








Rate 


1/6 




1/3 








20/27 








Rate 


0.17 




0.33 








0.74 








Sch 










10.00 


10.00 


10.00 








MPR 










1.00 


2.00 


4.00 








MOD 










2.00 


4.00 


6.00 








Rate 










1/2 


1/2 


2/3 








Rate 










0.50 


0.50 


0.67 
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Table 331— Transmission format and modulation level for DL (continued) 





144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 


12.00 


12.00 


12.00 


12.00 








12.00 






MPR 


0.25 


0.33 


0.50 


0.67 








5.00 






MUU 


z.UU 


z.UU 


O AA 

2.00 


2.00 








6.00 






Rate 


1/8 


1/6 


1/4 


1/3 








5/6 






Rate 


0.13 


0.17 


0.25 


0.33 








0.83 






Sch 












13.00 


13.00 


13.00 






MPR 












1.54 


3.08 


4.62 






MUU 












4.00 


6.00 


6.00 






Rate 












5/13 


20/39 


10/13 






Rate 












0.38 


0.51 


0.77 






Sch 










15.00 


15.00 


15.00 


15.00 






MPR 










0.67 


1.33 


2.67 


4.00 






MUU 










2.00 


2.00 


4.00 


6.00 






Rate 










1/3 


2/3 


2/3 


2/3 






Rate 










0.33 


0.67 


0.67 


0.67 






Sch 




16.00 




16.00 










16.00 




MPR 




0.25 




0.50 










5.00 




MUU 




2.00 




2.00 










6.00 




Rate 




1/8 




1/4 










5/6 




Rate 




0.13 




0.25 










0.83 




Sch 


18.00 




18.00 












18.00 




MPR 


0.17 




0.33 












4.44 




MUU 


2.00 




r\ f\r\ 

2.00 












6.00 




Rate 


1/12 




1/6 












20/27 




Rate 


0.08 




0.17 












0.74 




Sch 












20.00 


20.00 


20.00 


20.00 


20.00 


MPR 












0.50 


1.00 


2.00 


3.00 


5.00 


MOD 




< 








2.00 


2.00 


4.00 


6.00 


6.00 


Rate 












1/4 


1/2 


1/2 


1/2 


J/ U ! 


Rate 












0.25 


0.50 


0.50 


0.50 


0.83 


Sch 
















22.00 




22.00 


MPR 
















2.73 




4.55 


MOD 
















4.00 




6.00 


Rate 
















15/22 




25/33 


Rate 
















0.68 




0.76 


Sch 




24.00 


24.00 


24.00 














MPR 




0.17 


0.25 


0.33 














MUU 




2.00 


2.00 


2.00 














Rate 




1/12 


1/8 


1/6 














Rate 




0.08 


0.13 


0.17 














Sch 














26.00 




26.00 


26.00 


MPR 














1.54 




3..08 


3.85 


MOD 














a on 




o.uu 


O.UU | 


Rate 














5/13 




20/39 


25/39 \ 


Rate 














0.38 




0.51 


0.64 


Sch 










30.00 


30.00 


30.00 


30.00 


30.00 




MPR 










0.33 


0.67 


1.33 


2.00 


2.67 




MOD 










2.00 


2.00 


2.00 


4.00 


4.00 




Rate 










1/6 


1/3 


2/3 


1/2 


2/3 




Rate 










0.17 ' 


0.33 


0.67 


0.50 


0.67 
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Table 331— Transmission format and modulation level for DL (continued) 



N EP 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 

MPR 

MOD 

Rate 

Rate 








32.00 

0.25 

2.00 

1/8 

0.13 












32.00 
3.13 

£ r\f\ 

25/48 
0.52 


Sch 

MPR 

MOD 

Rate 

Rate 




















38.00 
2.63 

4.UU 

25/38 
0.66 


Sch 

MPR 

MOD 

Rate 

Rate 










40.00 

0.25 

2.00 

1/8 

0.13 


40.00 

0.50 

2.00 

1/4 

0.25 


40.00 

1.00 

2.00 

1/2 

0.50 


40.00 

1.50 

4.00 

3/8 

0.38 


40.00 

2.00 

4.00 

1/2 

0.50 




Sch 

MPR 

MOD 

Rate 

Rate 
















44.00 

1.36 

2.00 

15/22 

0.68 






Sch 

MPR 

MOD 

Rate 

Rate 








48.00 

0.17 

2.00 

1/12 

0.08 














Sch 

MPR 

MOD 

Rate 

Rate 




















50.00 
2.00 

A AA 

4.00 

1/2 

0.50 


Sch 

MPR 

MOD 

Rate 

Rate 


















52.00 

1.54 

4.00 

5/13 

0.38 




Sch 

MPR 

MOD 

Rate 

Rate 










60.00 

0.17 

2.00 

1/12 

0.08 


60.00 

0.33 

2.00 

1/6 

0.17 


60.00 

0.67 

2.00 

1/3 

0.33 


60.00 

1.00 

2.00 

1/2 

0.50 


60.00 

1.33 

2.00 

2/3 

0.67 




Sch 

MPR 

MOD 

Rate 

Rate 




















64.00 

1.56 

4.00 

25/64 

0.39 


Sch 

MPR 

MOD 

Rate 

Rate 




















76.00 

1.32 

2.00 

25/38 

0.66 
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Table 331— Transmission format and modulation level for DL (continued) 



n E p 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 

MPR 

MOD 

Rate 

Rate 












80.00 

0.25 

2.00 

1/8 

0.13 


80.00 

0.50 

2.00 

1/4 

0.25 




80.00 

1.00 

2.00 

1/2 

0.50 




Sch 

MPR 

MOD 

Rate 

Rate 
















90.00 

0.67 

2.00 

1/3 

0.33 






Sch 

MPR 

MOD 

Rate 

Rate 




















100.00 

1.00 

2.00 

1/2 

0.50 


Sch 

MPR 

MOD 

Rate 

Rate 












120.00 

0.17 

2.00 

1/12 

0.08 


120.00 

0.33 

2.00 

1/6 

0.17 


120.00 

0.50 

2.00 

1/4 

0.25 


120.00 

0.67 

2.00 

1/3 

0.33 




Sch 

MPR 

MOD 

Rate 

Rate 




















150.00 

0.67 

2.00 

1/3 

0.33 


Sch 

MPR 

MOD 

Rate 

Rate 














160.00 

0.25 

2.00 

1/8 

0.13 




160.00 

0.50 

2.00 

1/4 

0.25 




Sch 

MPR 

MOD 

Rate 

Rate 
















180.00 

0.33 

2.00 

1/6 

0.17 






Sch 

MPR 

MOD 

Rate 

Rate 




















200.00 

0.50 

2.00 

1/4 

0.25 


Sch 

MPR 

MOD 

Rate 
Rate 














240.00 
0.17 
o fin 

1/12 
0.08 


240.00 

0.25 

Z.UU 

1/8 
0.13 


240.00 
0.33 . 

2.00 
1/6 

0.17 




Sch 

MPR 

MOD 

Rate 

Rate 




















300.00 

0.33 

2.00 

1/6 

0.17 
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N E p 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 

MPR 

MOD 

Rate 

Rate 


















320.00 

0.25 
<-> f\f\ 
2.UU 

1/8 

0.13 




Sch 

MPR 

MOD 

Rate 

Rate 
















360.00 

0.17 

2.00 

1/12 

0.08 






Sch 

MPR 

MOD 

Rate 

Rate 




















400.00 

0.25 

2.00 

1/8 

0.13 


Sch 

MPR 

MOD 

Rate 

Rate 


















480.00 

0.17 

2.00 

1/12 

0.08 





Table 332— N EP encoding 





48 


96 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


9600 


14400 


19200 


24000 


Encod- 
ing 


0 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 



8.4.9.2.3.5.7 Modulation order of UL traffic burst 

For UL, the modulation order (2 for QPSK and 4 for 16-QAM) shall be set for all the allowed transmission 
formats as shown in Table 333. The transmission format is given by the N EP (Encoding Packet Size) and the 
N SCH (number of allotted subchannels). N EP per an encoding packet is {48, 96, 144, 192, 288, 384, 480, 960, 
1920, 2880, 3840, 4800}. The N SCH per an encoding packet is { 1...288}. In Table 333, the numbers in the 
first row are N E pS and the numbers in the remaining rows are N SCH 's and related parameters. 

The supportable modulation schemes are QPSK and 16-QAM. When the N EP and the N SCH are given, the 
modulation order is determined by the value of MPR. The MPR means the effective number of the 
information bit transmitted per subcarrier and is defined by Equation (129). 

MPR = j^f- (129) 
Then, the modulation order is specified by the following rule: 
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If 0 < MPR < 1.5 , then a QPSK (modulation order 2) is used. 

If 1 .5 < MPR < 3.4 , then a 16-QAM (modulation order 4) is used. 

The effective code rate is equal to MPR divided by the modulation order (i.e., 2 for QPSK). 

The information of N EP and N SCH shall be signaled in UL MAP. Instead of the actual values of N EP and 
N SCH> toe encoded value of N EP (N EP code) and N SCH (N SCH code) shall be used for the signaling. They are 
encoded by 4 bits, respectively. The encoding of N EP (N EP code) is shown in Table 332. The encoding of 
N SCH (Nsch code) is performed per N EP value. For each N EP > there are less than 16 kinds of N SCH values and 
they are encoded from "0"(the smallest number of subchannels) to "15" in increasing order. When the' 
number of N SCH values for a N EP is smaller than 16, then the corresponding number of codes is used. When 
the fragmentation is applied and the number of the subpackets for an allocation is n, n*N EP and N SCH (the 
number of subchannels allocated for a subpacket) should be signaled. 

The encoding for n*N EP (N EP code) is also shown in Table 332. The encoded value of N SCH (N SCH code) 
should be interpreted as N SCH for a subpacket, and n*N SCH for the whole allocation. 



Table 333 — Transmission format and modulation level for UL 



Hep 


AO 

48 


96 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 


1.00 


1.00 


1.00 




















MPR 


1.00 


2.00 


3.00 




















MOD 


2.00 


4.00 


4.00 




















Rate 


1/2 


1/2 


3/4 




















Rate 


0.50 


0.50 


0.75 




















Sch 


2.00 


2.00 


2.00 


2.00 


2.00 
















MPR 


0.50 


1.00 


1.50 


2.00 


3.00 
















MOD 


2.00 


2.00 


4.00 


4.00 


4.00 
















Rate 


1/4 


1/2 


3/8 


1/2 


3/4 
















Rate 


0.25 


0.5 


0.38 


0.50 


0.75 
















Sch 


3.00 


3.00 


3.00 


3.00 


3.00 


3.00 


3.00 












MPR 


0.33 


0.67 


1.00 


1.33 


2.00 


2.67 


3.33 












MOD 


2.00 


2.00 


2.00 


2.00 


4.00 


4.00 


4.00 












Rate 


1/6 


1/3 


1/5 


2/3 


1/2 


2/3 


5/6 












Rate 


0.17 


0.33 


0.50 


0.67 


0.5 


0.67 


0.83 












Sch 


4.00 


4.00 




4.00 


4.00 


4.00 


4.00 












MPR 


0.25 


0.50 




1.00 


1.50 


2.00 


2.50 












MOD 


2.00 


2.00 




2.00 


4.00 


4.00 


4.00 












Rate 


1/8 


1/4 




1/2 


3/8 


1/2 


5/8 












Rate 


0.13 


0.25 




0.50 


0.38 


0.50 


0.63 












Sch 






5.00 




5.00 


5.00 


5.00 












MPR 






0.60 




1.20 


1.60 


2.00 












MOD 






2.00 




2.00 


4.00 


4.00 












Rate 






3/10 




3/5 


2/5 


1/2 












Rate 






0.30 




0.60 


0.40 


0.50 












Sch 


6.00 


6.00 


6.00 


6.00 


6.00 


6.00 


6.00 


6.00 










MPR 


0.17 


0.33 


0.50 


0.67 


1.00 


1.33 


1.67 


3.33 










MOD 


2.00 


2.00 


2.00 


2.00 


2.00 


2.00 


4.00 


4.00 










Rate 


1/12 


1/6 


1/4 


1/3 


1/2 


2/3 


5/12 


5/6 










Rate 


0.08 


0.17 


0.25 


0.33 


0.50 


0.67 


0.42 


0.83 











Copyright ©2004 IEEE. All rights reserved. 



611 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



Table 333— Transmission format and modulation level for UL (continued) 



N E P 


48 


96 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 
















7.00 










MPR 
















2.86 










MOD 
















4.00 










Rate 
















5/7 










Rate 
















.0.714 










Sch 




8.00 




8.00 




8.00 


8.00 


8.00 










MPR 




0.25 




0.50 




1.00 


L25 


2.50 










MOD 




2.00 




2.00 




2.00 


2.00 


4.00 










Rntf* 

fxalC 




1/8 




1/4 




1/2 


5/8 


5/8 










Rate 




0.13 




0.25 




0.50 


0.63 


0.63 










Sch 






9.00 




9.00 
















MPR 






0.33 




0.67 
















MOD 






2.00 




2.00 
















Rate 






1/6 




1/3 
















Rate 






0.17 




0.33 
















Sch 














10.00 


10.00 










MPR 














1.00 


2.00 










MOD 














2.00 


4.00 










Rate 














1/2 


1/2 
























0.50 


0.50 










Sch 




12.0 


12.00 


12.0 


12.0 


12.0 






12.0 








MPR 




0.17 


0.25 


0.33 


0.50 


0.67 






3.33 








MOD 




2.0 


2.00 


2.00 


2.00 


2.00 






4.00 








Kd.lt 




1/1? 


1/8 


1/6 


1/4 


1/3 






5/6 








R ntf> 
ivaic 




0.08 


0.13 


0.17 


0.25 


0.33 






0.83 








Sch 


















13.00 








MPR 


















3.08 








MOD 


















3.00 








Rate 


















10/13 








Rate 


















0.77 








Sch 














15.00 


15.00 


15.00 








MPR 














0.67 


1.33 


2.67 








MOD 














2.00 


2.00 


4.00 








Rate 














1/3 


2/3 


2/3 








R 9tP 














0.33 


0.67 


0.67 








Sch 








16.0 




16.0 














MPR 








0 




0 














MOD 








0.25 




0.50 














Rate 








2.00 




2.00 














Kaie 








1/8 

1/ o 




1/4 






















0.13 




0.25 














Sch 






18.00 




18.0 












18.00 




MPR 






0.17 




0.33 












3.33 




MOD 






2.00 




z.ou 
















Rate 






1/12 




1/6 












5/6 




Rate 






0.08 




0.17 












0.83 




Sch 
















20.00 


20.00 


20.00 


20.0 




MPR 
















0.50 


1.00 


2.00 


3.00 




MOD 
















2.00 


2.00 


4.00 


4.00 




Rate 
















1/4 


1/2 


1/2 


3/4 




Rate 
















0.25 


0.50 


0.50 


0.75 
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Table 333— Transmission format and modulation level for UL (continued) 





48 


96 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 

MPR 

MOD 

Rate 

Rate 








24.0 
0.17 
2.00 
1/12 
0.08 


24.0 

0.25 

2.00 

1/8 

0.13 


24.0 

0.33 

2.00 

1/6 

0.17 








24.0 

2.50 

4.00 

5/8 

0.63 


24.0 

3.33 

4.0 

5/6 

0.83 




Sch 

MPR 

MOD 

Rate 

Rate 


















26.00 

1.54 

4.00 

5/13 

0.38 




26.0 

3.08 

4.00 

10/13 

0.77 




Sch 

MPR 

MOD 

Rate 

Rate 














30.00 

0.33 

2.00 

1/6 

0.17 


30.00 

0.67 

2.00 

1/3 

0.33 


30.00 

1.33 

2.00 

2/3 

0.67 


30.00 

2.00 

4.00 

1/2 

0.50 


30.00 

2.67 

4.00 

2/3 

0.67 


30.0 

3.33 

3.00 

5/6 

0.83 


Sch 

MPR 

MOD 

Rate 

Rate 












32.0 

0.25 

2.00 

1/8 

0.13 














Sch 

MPR 

MOD 

Rate 

Rate 
























34.0 

2.94 

4.00 

25/34 

0.74 


Sch 

MPR 

MOD 

Rate 

Rate 










36.0 
0.17 
2.00 
1/12 
0.08 
















Sch 

MPR 

MOD 

Rate 

Rate 
























38.00 

2.63 

4.00 

25/38 

0.66 


Sch 

MPR 

MOD 

Rate 

Rate 














40.00 

0.25 

2.00 

1/8 

0.13 


40.00 

0.50 

2.00 

1/4 

0.25 


40.00 

1.00 

2.00 

1/2 

0.50 


40.00 

1.50 

4.00 

3/8 

0.38 


40.00 

2.00 

4.00 

1/2 

0.50 




Sch 
MPR 

MUU 

Rate 
Rate 




















45.0 

1.33 

2.00 

2/3 

0.67 






Sch 

MPR 

MOD 

Rate 

Rate 












48.0 
0.17 
2.00 
1/12 
0.08 
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Table 333— Transmission format and modulation level for UL (continued) 



Nep 


48 


96 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 

MPR 

MOD 

Rate 

Rate 
























50.00 

2.00 

4.00 

1/2 

0.50 


Sch 

MPR 

MOD 

Rate 

Rate 






















52.00 

1.54 

4.00 

5/13 

0.38 




Sch 

MPR 

MOD 

Rate 

Rate 














60.00 

0.17 

2.00 

1/12 

0.08 


60.00 

0.33 

2.00 

1/6 

0.17 


60.00 

0.67 

2.00 

1/3 

0.33 


60.00 

1.00 

2.00 

1/2 

0.50 


60.00 

1.33 

2.00 

2/3 

0.67 




Sch 

MPR 

MOD 

Rate 

Rate 
























66.0 

1.52 

4.00 

25/66 

0.38 


Sch 

MPR 

MOD 

Rate 

Rate 
























76.00 

1.32 

2.00 

25/38 

0.66 


Sch 

MPR 

MOD 

Rate 

Rate 
















80.00 

0.25 

2.00 

1/8 

0.13 


80.00 

0.50 

2.00 

1/4 

0.25 




80.00 

1.00 

2.00 

1/2 

0.50 




Sch 

MPR 

MOD 

Rate 

Rate 




















90.00 

0.67 

2.00 

1/3 

0.33 






Sch 

MPR 

MOD 

Rate 

Rate 
























100.00 

1.00 

2.00 

1/2 

0.50 


Sch 

MPR 

MOD 

Rate 

Rate 
















120.0 

0.17 

2.00 

1/12 

0.08 


120.00 

0.33 

2.00 

1/6 

0.17 


120.00 

0.50 

2.00 

1/4 

0.25 


120.00 

0.67 

2.00 

1/3 

0.33 




Sch 

MPR 

MOD 

Rate 

Rate 
























150.00 

0.67 

2.00 

1/3 

0.33 
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Table 333— Transmission format and modulation level for UL (continued) 



Hep 


48 


96 


144 


192 


288 


384 


480 


960 


1920 


2880 


3840 


4800 


Sch 

MPR 

MOD 

Rate 

Rate 


















160.00 

0.25 

2.00 

1/8 

0.13 




160.00 

0.50 

2.00 

1/4 

0.25 




Sch 

MPR 

MOD 

Rate 

Rate 




















180.00 

0.33 

2.00 

1/6 

0.17 






Sch 
MPR 

LVIkJLJ 

Rate 
Rate 
























200.00 

0.50 

2.00 

1/4 

0.25 


Sch 

MPR 

MOD 

Rate 

Rate 


















240.00 

0.17 

2.00 

1/12 

0.08 


240.00 

0.25 

2.00 

1/8 

0.13 


240.00 

0.33 

2.00 

1/6 

0.17 





8.4.9.2.4 Zero tailed convolutional coding (optional) 



The convolutional encoder (as described in 8.4.9.2.1) may employ the Zero Tailing technique. In this case, a 
single 0x00 tail byte is appended at the end of each burst. This tail byte shall be appended after 
randomization. The convolutional code and the puncturing shall be applied to the whole burst without 
partitioning it into blocks. The interleaving shall be applied to the coded bits in blocks of size described in 
8.4.9.2. 

8.4.9.3 Interleaving 

All encoded data bits shall be interleaved by a block interleaver with a block size corresponding to the 
number of coded bits per the encoded block size N c5ps as set in 8.4.9.2. The interleaver is defined by a two- 
step permutation. The first ensures that adjacent coded bits are mapped onto nonadjacent subcarriers. The 
second permutation insures that adjacent coded bits are mapped alternately onto less or more significant bits 
of the constellation, thus avoiding long runs of lowly reliable bits. 

Let yv cpc be the number of coded bits per subcarrier, i.e., 2, 4, or 6 for QPSK, 16-QAM or 64-QAM, 
respectively. Let s = N cpc /2. Within a block of N c5ps bits at transmission, let k be the index of the coded bit 
before the first permutation, m k be the index of that coded bit after the first and before the second 
permutation and let j k be the index after the second permutation, just prior to modulation mapping, and d be 
the modulo used for the permutation. 

The first permutation is defined by Equation (130): A: = 0,1,... ,/V cbps - 1 , d = 1 6 

m k - W cbps /d) • k mod{d) +floor(k/d) k = 0, 1, 7V cbps - 1 d = 16 (130) 

The second permutation is defined by Equation (131): ' 

j k = s floor(m k /s) + (m k + N cbps -floor(d- m k /N cbvs )) modU) k = 0, 1, ...,N cbps - 1 d = 16 (131) 
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The de-interleaver, which performs the inverse operation, is also defined by two permutations. Within a 
received block of Af cbps bits, let j be the index of a received bit before the first permutation; ntj be the index 
of that bit after the first and before the second permutation; and let h } be the index of that bit after the second 
permutation, just prior to delivering the block to the decoder. 



j = 0, l,...,tf cbps -l 



The first permutation is defined by Equation (132): 
m j = sfloor(j/s) + (j+floor(dj/N chps )) mod{s) 

The second permutation is defined by Equation (133): 

k r d m r {N cb ^-\) floor{d m/N^) j = 0, 1, .... N cbps - 1 



16 



16 



(132) 



(133) 



The first permutation in the de-interleaver is the inverse of the second permutation in the interleaver, and 
conversely. 

8.4.9.4 Modulation 

8.4.9.4.1 Permutation definition 

The PRBS generator depicted hereafter shall be used to produce a sequence, w k (see Figure 262). The 
polynomial for the PRBS generator shall be X 11 + X 9 + 1. 



MSB 



LSB 



Initialization 


DL: 1 


1 


1 


1 


1 


1 


1 


1 


1 


1 


1 


Sequences 


UL: 1 


0 


1 


0 


1 


0 


1 


0 


1 


0 
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1 


2 


3 


4 


5 


6 


7 


8 


9 


10 
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Figure 262— PRBS for pilot modulation 

The value of the pilot modulation, on subcarrier k, shall be derived from w k . 

The initialization vector of the PRBS for both uplink and downlink shall be designated M0..b0, such that: 

M0..b6 = Five least significant bits of IDcell as indicated by the frame preamble, except for zones 

marked by "Use all SC indicator = 1," where these bits shall be set to 1, in the downlink. Five 
least significant bits of ULJDcell in the uplink 
b5..b4 = Set to the segment number + 1 as indicated by the frame preamble, except for zones marked by 

"Use all SC indicator = 1," where these bits shall be set to 1 
b3..b0 = Four least significant bits of symbol offset from the first data symbol in the frame (i.e., the 
symbol in the frame in which the DL-MAP starts) 

For example, should the initialization vector of the PRBS be bl0..b0 = 10101010101, the initializations 
result in the sequence w k = 10101010101000000000.... in the uplink. The PRBS shall be initialized so that 
its first output bit coincides with the first usable subcarrier (as defined in Table 313). A new value shall be 
generated by the PRBS for every subcarrier up to the highest numbered usable subcarrier, including the DC 
subcarrier. 
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8.4.9.4.2 Data modulation 

After bit interleaving, the data bits are entered serially to the constellation mapper. Gray-mapped QPSK and 
16-QAM (as shown in Figure 263) shall be supported, whereas the support of 64-QAM is optional. The 
constellations (as shown in Figure 263) shall be normalized by multiplying the constellation point with the 
indicated factor c to achieve equal average power. 

Per-allocation adaptive modulation and coding shall be supported in the downlink. The uplink shall support 
different modulation schemes for each SS based on the MAC burst configuration messages coming from the 
BS. Complete description of the MAC/PHY support of adaptive modulation and coding is provided in 6.3.7. 
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Figure 263— QPSK, 16-QAM, and 64-QAM constellations 



001 000 010 011 b 5 b 4 b 3 



The constellation-mapped data shall be subsequently modulated onto the allocated data subcarriers and each 
subcarrier multiplied by the factor 2*(l/2 - wjj according to the subcarrier index, k. 

8.4.9.4.3 Pilot modulation 

For the mandatory tile structure in the uplink, pilot subcarriers shall be inserted into each data burst in order 
to constitute the Symbol and they shall be modulated according to their subcarrier location within the 
OFDMA symbol. 

The Pilot subcarriers shall be modulated according to Equation (134): 



Re{c,}= 2(1 
lm{c k } = 0 



(134) 
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In the downlink and for the optional uplink tile structure each pilot shall be transmitted with a boosting of 
2.5 dB over the average power of each data tone. The Pilot subcarriers shall be modulated according to 
Equation (135): 



\m{c k } = 0 

8.4.9.4.3.1 Preambles/midambles pilot modulation 

The pilots in the downlink preamble shall follow the instructions in 8.4.6.1.1, and shall be modulated 
according to Equation (136): 

Re{PreamblePilotsModulated}= 4 • ^2 • (i - vv^ (136) 
\m{PreamblePilotsModulated} - 0 

8.4.9.4.3.2 Ranging pilot modulation 

The BPSK modulation on the ranging transmissions, real and imaginary parts, is defined by Equation (137): 

. Re{c,} = 2(1/2-^) (137) 
lm{c k } =0 

where c k is the fc-th subcarrier of the Ranging Channel, and C k is the k-th bit of the code generated according 
to 8.4.7.3 

8.4.9.4.4 Example of OFDMA uplink CC encoding 

An example of one burst of OFDMA uplink using mandatory structure is provided, illustrating each process 
from randomization through subcarrier modulation. The scenario parameters are as follows: 

1) OFDM symbol number start = 35 

2) Number of time slots in UL allocation = 2 

3) Starting Logical Slot = 6 (mapped onto physical subchannel 16 in the first time slot and physical 
subchannel 17 in the second time slot due to subchannel rotation) 

4) IDcell = 5 

5) Segment = 0 

6) Modulation = QPSK 

7) Coding scheme = Convolutional coding 

8) Coding rate = 1/2 

Input Data (Hex) 

AC BC D2 11 4D AE 15 77 C6 DB F4 C9 
Randomized Data (Hex) 

06 DF 2F 59 42 IE 34 D7 03 19 68 46 
Convolutional encoded Data (Hex) 

36 F5 El 7E E8 98 6E 27 EB B9 F2 A6 57 B6 AO 51 FA BD 4E E0 E5 A9 E7 F2 




(135) 
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Interleaved Data (Hex) 

6D BB DF FD B4 94 38 C6 1B9ED8 53 AE FC 2A DE FD 76 68 AE94 56 1665 

Constellation Mapping (data shall be transformed to constellation values: I value/Q value. The value 0.707 
represents sqrt(2)/2),: 

+0.707/-0.707, -0.707/+0.707, -0.707/-0.707, +0.707/-0.707, -0.707/+0.707, -0.707/-0.707, -0.707/ 
+0.707, -0.707/-0.707, -0.707/-0.707, +0.707/-0.707, -0.707/-0.707, -0.707/-0.707, -0.707/-0.707, - 
0.707/-0.707, -0.707/-0.707, +0.707/-0.707, -0.707/+0.707, -0.707/-0.707, +0.707/-0.707, +0.707/ 
+0.707, -0.707/+0.707, +0.707/-0.707, +0.707/-0.707, +0.707/+0.707, +0.707/+0.707, -0.707/- 
0.707, -0.707/+0.707, +0.707/+0.707, -0.707/-0.707, +0.707/+0.707, +0.707/-0.707, -0.707/+0.707, 
+0.707/+0.707, +0.707/-0.707, -0.707/+0.707, -0.707/-0.707, -0.707/+0.707, +0.707/-0.707, -0.707/ 
-0.707, -0.707/+0.707, -0.707/-0.707, +0.707/-0.707, -0.707/+0.707, +0.707/+0.707, +0.707/-0.707, 
+0.707/-0.707, +0.707/+0.707, -0.707/-0.707, -0.707/+0.707, -0.707/+0.707, -0.707/-0.707, -0.707/ 
+0.707, -0.707/-0.707, -0.707/-0.707, -0.707/-0.707, +0.707/+0.707, +0.707/+0.707, -0.707/+0.707, 
-0.707/+0.707, -0.707/+0.707, -0.707/-0.707, +0.707/-0.707, -0.707/-0.707, -0.707/+0.707, -0.707/- 
0.707, -0.707/-0.707, -0.707/-0.707, +0.707/-0.707, +0.707/-0.707, -0.707/-0.707, +0.707/-0.707, - 
0.707/+0.707, +0.707/-0.707, -0.707/+0.707, -0.707/+0.707, +0.707/+0.707, -0.707/+0.707, -0.707/ 
+0.707, -0.707/-0.707, -0.707/+0.707, -0.707/+0.707, +0.707/-0.707, +0.707/-0.707, +0.707/+0.707, 
+0.707/-0.707, +0.707/-0.707, +0.707/-0.707, -0.707/+0.707, +0.707/+0.707, +0.707/-0.707, 
+0.707/-0.707, -0.707/+0.707, +0.707/-0.707, -0.707/+0.707, +0.707/-0.707, +0.707/-0.707 

Mapping onto subcarriers and multiplying by PN [assuming the use of logical data subchannel 6, mapped 
onto physical subchannel 16 in the first time slot and to physical subchannel 17 at the second time slot, 
structure includes pilots and is in the structure of (Symbol Number, Subcarrier Index, I value / Q Value)]: 

(35.448.+1/0), (35,449,-0.707/+0.707), (35,450,-0.707/-0.707), (35,451, +1/0), (35,512,+l/0), 
(35,513,-0.707/+0.707), (35,514,-0.707/-0.707), (35,515,-1/0), (35,984,+ 1/0), (35,985,-0.707/- 
0.707), (35,986,+O.707/-0.707), (35,987,+l/0), (35,1189,-1/0), (35,1190,-0.707/-0.707), (35,1191,- 
0.707/-0.707), (35,1192,+l/0), (35.1505.+1/0), (35,1506,+0.707/-0.707), (35,1507,-0.707/+0.707), 
(35.1508.+1/0), (35,1753,-1/0), (35,1754,-0.707/-0.707), (35,1 755, +0.707/-0.707), (35,1756,+l/0), 
(36,448,-0.707/+0.707), (36,449,+0.707/-0.707), (36,450,+0.707/-0.707), (36,45 1,+0.707/+0.707), 
(36,512,+0.707/+0.707), (36,513,-0.707/-0.707), (36,514,-0.707/+0.707), (36,515,+0.707/+0.707), 
(36,984,-0.707/-0.707), (36,985,+0.707/+0.707), (36,986,+0.707/-0.707), (36,987,-0.707/+0.707), 
(36,1189,+0.707/+0.707), (36,1190,+0.707/-0.707), (36,1191,-0.707/+0.707), (36,1192,-0.707/- 
0.707), (36,1505,-0.707/-0.707), (36,1506,-0.707/-0.707), (36,1507,-0.707/-0.707), 
(36,1508,+0.707/-0.707), (36,1753,-0.707/+0.707), (36,1754,-0.707/-0.707), (36, 1755 ,+0.707/- 
0.707), (36,1756,+0.707/+0.707), (37,448,+l/0), (37,449,-0.707/-0.707), (37,450,+0.707/-0.707), 
(37,451,-1/0), (37,5 12,+ 1/0), (37,513,-0.707/+0.707), (37,514,+0.707/+0.707), (37,5 15,+ 1/0), 
(37,984,+l/0), (37,985,+0.707/-0.707), (37,986,+0.707/-0.707), (37,987,+l/0), (37,1 189,+ 1/0), 
(37,1190,+0.707/+0.707), (37,1 191, -0.707/-0.707), (37, 11 92,+ 1/0), (37,1505,-1/0), (37,1506,-0.707/ 
+0.707), (37,1507,+0.707/-0.707), (37,1508,-1/0), (37,1753,+l/0), (37,1754,-0.707/-0.707), 
(37,1755,-0.707/+0.707), (37,1756,-1/0), (38,232,+l/0), (38,233,+l/0), (38,234,-0.707/+0.707), 
(38,235,-0.707/+0.707), (38,704,+l/0), (38,705,+l/0), (38,706,-0.707/+0.707), (38,707,-0.707/ 
+0.707), (38,908,+l/0), (38,909,+l/0), (38,910,-0.707/-0.707), (38,911,-0.707/+0.707), 
(38,1225,+l/0), (38.1226.+1/0), (38,1227,-0.707/-0.707), (38,1228,-0.707/-0.707), (38,1473,+l/0), 
(38,1474,+l/0), (38,1475,-0.707/-0.707), (38,1476,+0.707/+0.707), (38.1813.+1/0), (38.1814.+1/0), 
(38,1815,+0.707/+0.707), (38,1816,-0.707/+0.707), (39,232,-0.707/+0.707), (39,233,-0.707/ 
+0.707), (39,234,+0.707/-0.707), (39,235,+0.707/-0.707), (39,704,+0.707/+0.707), (39,705,-0.707/- 
0.707), (39,706,+0.707/-0.707), (39,707,-0.707/-0.707), (39,908,-0.707/+0.707), (39,909,-0.707/- 
0.707), (39,910,-0.707/-0.707), (39,91 1.-0.707/-0.707), (39.1225.+0.707/-0.707), (39,1226,+0.707/- 
0.707), (39,1227,-0.707/-0.707), (39,1228,+0.707/-0.707), (39,1473,-0.707/+0.707), 
(39,1474,+0.707/-0.707), (39,1475,-0.707/+0.707), (39,1476,-0.707/+0.707), (39,1 8 13, +0.707/ 
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+0.707), (39,1814,-0.707/+0.707), (39,1815,-0.707/+0.707), (39,1816,-0.707/-0.707), (40,232,+l/ 
0), (40,233,+l/0), (40,234,+0.707/-0.707), (40,235,+0.707/-0.707), (40,704,+ 1/0), (40,705,+l/0), 
(40,706,+0.707/-0.707), (40,707,+0.707/-0.707), (40,908,+ 1/0), (40,909,+ 1/0), (40,910,+0.707/- 
0.707), (40,91 1,-0.707/+0.707), (40, 1225 ,+1/0), (40, 1226,+ 1/0), (40,1 227, +0.707/+0. 707), 
(40,1228,+0.707/-0.707), (40, 1473,+ 1/0), (40, 1474,+ 1/0), (40,1475,+0.707/-0.707), (40,1476,- 
0.707/+0.707), (40,1813,+l/0), (40,18 14,+l/0), (40,1815,+0.707/-0.707), (40,1816,-0.707/+0.707), 

8.4.10 Control mechanisms 

8.4.10.1 Synchronization 

8.4.10.1.1 Network synchronization 

For TDD and FDD realizations, it is recommended (but not required) that all BSs be time synchronized to a 
common timing signal. In the event of the loss of the network timing signal, BSs shall continue to operate 
and shall automatically resynchronize to the network timing signal when it is recovered. The synchronizing 
reference shall be a 1 pps timing pulse and a 10 MHz frequency reference. These signals are typically 
provided by a GPS receiver. 

For both FDD and TDD realizations, frequency references derived from the timing reference may be used to 
control the frequency accuracy of Base-Stations provided that they meet the frequency accuracy 
requirements of 8.4.14. This applies during normal operation and during loss of timing reference. 

8.4.10.1.2 SS synchronization 

For any duplexing, all SSs shall acquire and adjust their timing such that all uplink OFDMA symbols arrive 
time coincident at the BS to a accuracy of ± 25% of the minimum guard-interval or better. 

8.4.10.2 Ranging 

Ranging for time (coarse synchronization) and power is performed during two phases of operation: during 
(re)registration and when synchronization is lost; and second, during FDD or TDD transmission on a 
periodic basis. 

During registration, a new subscriber registers using the random access channel, and if successful, is entered 
into a ranging process under control of the BS. The ranging process is cyclic in nature where default time 
and power parameters are used to initiate the process followed by cycles where (re)calculated parameters are 
used in succession until parameters meet acceptance criteria for the new subscriber. These parameters are 
monitored, measured, and stored at the BS, and transmitted to the subscriber unit for use during normal 
exchange of data. During normal exchange of data, the stored parameters are updated in a periodic manner 
based on configurable update intervals to ensure changes in the channel can be accommodated. The update 
intervals shall vary in a controlled manner on a subscriber unit by subscriber unit basis. 

Ranging on re-registration follows the same process as new registration. 

8.4.10.3 Power control 

A power control algorithm shall be supported for the uplink channel with both an initial calibration and 
periodic adjustment procedure without loss of data. The BS should be capable of providing accurate power 
measurements of the received burst signal. This value can then be compared against a reference level, and 
the resulting error can be fed back to the SS in a calibration message coming from the MAC. The power 
control algorithm shall be designed to support power attenuation due to distance loss or power fluctuations 
at rates of at most 30 dB/s with depths of at least 10 dB for fixed deployment. The exact algorithm 
implementation is vendor-specific. The total power control range consists of both a fixed portion and a 
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portion that is automatically controlled by feedback. The power control algorithm shall take into account the 
interaction of the RF power amplifier with different burst profiles. For example, when changing from one 
burst profile to another, margins should be maintained to prevent saturation of the amplifier and to prevent 
violation of emissions masks. 

A transmitting SS shall maintain the same transmitted power density regardless of the number of 
subchannels assigned, unless the maximum power level is reached. That is, when the number of active 
subchannels allocated to a user is reduced, the total transmitted power shall be reduced proportionally by the 
SS, without additional power control messages. When the number of subchannels is increased, the total 
transmitted power shall also be increased proportionally. However, the transmitted power level shall not 
exceed the maximum levels dictated by signal integrity considerations and regulatory requirements. The SS 
shall interpret power control messages as the required changes to the transmitted power density. 

To maintain at the BS a power density consistent with the modulation and FEC rate used by each SS, the BS 
may change the SS TX power as well as the SS assigned modulation and FEC rate. There are, however, 
situations where the SS should automatically update its TX power, without being explicitly instructed by the 
BS. This happens when the SS transmits in region marked by UIUC = 0, UIUC = 12, or UIUC = 14. In all 
these situations, the SS shall use a temporary TX power value set according to Equation (138) (in dB), 

^new = ^last + ( C/N new ~ C/N last ) - {\Qg\Wnew) ~ \og\0{R last )) (138) 

where, 

P new is the temporary TX Power, 

Plan is the last used TX Power, 

C/N new is the normalized C/N of new modulation/FEC rate instructed by the UIUC, 

C/N last is tne normalized C/N of the last used modulation/FEC rate, 

R new is the number of repetitions for the new modulation/FEC rate instructed by the UIUC, 

Rfast is the number of repetitions on the last used modulation/FEC rate. 

The default normalized C/N values per modulation are given by Table 334. These values may be overridden 
by the BS by using a dedicated UCD message TLV. 



Table 334— Normalized C/N per modulation 



Modulation/ 
FEC rate 


Normalized C/N 


Fast_feedback IE 


0 


CDMA code 


3 


QPSK 1/2 


6 


QPSK 3/4 


9 


16-QAM 1/2 


12 


16-QAM 3/4 


15 


64-QAM 1/2 


18 
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Table 334— Normalized C/N per modulation (continued) 



Modulation/ 
FEC rate 


Normalized C/N 


64-QAM 2/3 


20 


64QAM 3/4 


21 


64QAM 5/6 


23 



To maintain at the BS a power density consistent with the modulation used by each SS, the BS may change 
the SS TX power as well as the SS assigned modulation and FEC rate. There are, however, situations where 
the SS should automatically update its TX power, without being explicitly instructed by the BS. This hap- 
pens when the SS transmits in region marked by UIUC = 0, UIUC = 12, or UIUC = 14. In all these situa- 
tions, the SS shall use a temporary TX power value set according to the formula Temporary_TX_Power = 
Last_TX_Power_Normalized_C/N_ofJast_modualtion + Normalized_C/N_of_QPSK_l/2_modulation. 

The SS shall report the maximum available power and the normalized transmitted power. These parameters 
may be used by the base station for optimal assignment of coding schemes and modulations and also for 
optimal allocation of subchannels. The algorithm is vendor-specific. These parameters are reported in the 
REG-RSP message. The current transmitted power shall also reported in the RNG-RSP message if the 
relevant flag in the REP-REQ message has been set. 

The current transmitted power is the power of the burst that carries the message. The maximum available 
power is reported for QPSK QAM 16 and QAM 64 constellations. The current transmitted power and the 
maximum power parameters are reported in dBm. The parameters are quantized in 0.5dBm steps ranging 
from ~-64dBm (encoded 0x00) to 63.5dBm (encoded OxFF). Values outside this range shall be assigned the 
closest extreme. SSs that do not support QAM64 shall report the value of 0x00 in the maximum QAM64 
power field. 

8.4.11 Channel quality measurements 

8.4.11.1 Introduction 

RSSI and CINR signal quality measurements and associated statistics can aid in such processes as BS 
selection/assignment and burst adaptive profile selection. As channel behavior is time- variant, both mean 
and standard deviation are defined. Implementation of the RSSI and CINR statistics and their reports is 
mandatory. 

The process by which RSSI measurements are taken does not necessarily require receiver demodulation 
lock; for this reason, RSSI measurements offer reasonably reliable channel strength assessments even at low 
signal levels. On the other hand, although CINR measurements require receiver lock, they provide 
information on the actual operating condition of the receiver, including interference and noise levels, and 
signal strength. 

8.4.11.2 RSSI mean and standard deviation 

When collection of RSSI measurements is mandated by the BS, an SS shall obtain an RSSI measurement 
(implementation- specific). From a succession of RSSI measurements, the SS shall derive and update 
estimates of the mean and the standard deviation of the RSSI, and report them via REP-RSP messages. 
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Mean and standard deviation statistics shall be reported in units of dBm. To prepare such reports, statistics 
shall be quantized in 1 dB increments, ranging from -40 dBm (encoded 0x53) to -123 dBm (encoded 0x00). 
Values outside this range shall be assigned the closest extreme value within the scale. 

The method used to estimate the RSSI of a single message is left to individual implementation, but the 
relative accuracy of a single signal strength measurement, taken from a single message, shall be ± 2 dB, with 
an absolute accuracy of ± 4 dB. This shall be the case over the entire range of input RSSIs. In addition, the 
range over which these single-message measurements are measured should extend 3 dB on each side beyond 
the -40 dBm to -123 dBm limits for the final averaged statistics that are reported. 

One possible method to estimate the RSSI of a signal of interest at the antenna connector is given by 
Equation (139): 



?1.2567 x 10V 2 



RSSI = 10 



10 



/V- 1 



(2 2B )R 



mW 



(139) 



n = 0 



where 

B is ADC precision, number of bits of ADC, 

R is ADC input resistance [Ohm], 

V c is ADC input clip level [Volts], 

G rt is analog gain from antenna connector to ADC input, 

Y lor Q[k> n J is "' th sample at the ADC output of / or g-branch within signal k, 

N is number of samples. 

The (linear) mean RSSI statistics (in mW), derived from a multiplicity of single messages, shall be updated 
using Equation ( 1 40); 



VrssiW = 

where 
k 

R[k] 



R[0] 

( 1 - ^ g )^RSSj[k - 1 ] + a avg /? [k] 



0 

k>0 



mW 



(140) 



is the time index for the message (with the initial message being indexed by k = 0, the next 
message by k = 1, etc.), 

is the RSSI in mW measured during message k, and a avg is an averaging parameter specified 
by the BS. 



The mean estimate in dBm shall then be derived from Equation (141). 
[k] = 10lQg(ji«55/[*i) dBm 



RSSI dBm 



(141) 



To solve for the standard deviation in dB, the expectation- squared statistic shall be updated using 
Equation (142), 



"'RSSI 



\R[0]\ 2 

(l-a a v 8 )^s^-n + « avg |/f[*]| 2 



* = 0 
*>0 



(142) 
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G 

RSS! dB 



and the result applied to Equation (143). 

= 51og(|4s5/[*l-(^s5/[^]) 2 |) dB (143) 
8.4.11.3 CINR mean and standard deviation 

When CINR measurements are mandated by the BS, an SS shall obtain a CINR measurement 
(implementation-specific). From a succession of these measurements, the SS shall derive and update 
estimates of the mean and the standard deviation of the CINR, and report them via REP-RSP messages. 

Mean and standard deviation statistics for CINR shall be reported in units of dB. To prepare such reports, 
statistics shall be quantized in 1 dB increments, ranging from a minimum of -10 dB (encoded 0x00) to a 
maximum of 53 dB (encoded 0x3F). Values outside this range shall be assigned the closest extreme value 
within the scale. 

The method used to estimate the CINR of a single message is left to individual implementation, but the rela- 
tive and absolute accuracy of a CINR measurement derived from a single message shall be ± 1 dB and 
±2dB, respectively. The specified accuracy shall apply to the range of CINR values starting from 3 dB 
below SNR of the most robust rate, to 10 dB above the SNR of the least robust rate. See Table 338. In addi- 
tion, the range over which these single-packet measurements are measured should extend 3 dB on each side 
beyond the -10 dB to 53 dB limits for the final reported, averaged statistics. 

One possible method to estimate the CINR of a single message is to compute the ratio of the sum of signal 
power and the sum of residual error for each data sample, using Equation (144). 

]>>[*, *]| 2 

CINR[*] = N _ } n = 0 — (144) 

^\r[k t n]-s[k f n]\ 2 

n=0 

where r[k,ri] received sample n within message k\ s[k,n] the corresponding detected or pilot sample (with 
channel state weighting) corresponding to received symbol n. 

The mean CINR statistic (in dB) shall be derived from a multiplicity of single messages using 
Equation (145). 

» CINRdB t*] = 101og(£oNR[*]) (145) 
where 

CINR[0] k = 0 



Ucinr[*] = 



(146) 

(l-a avg )HciNR[*-l] + a avg CINRm k>0 



k is the time index for the message (with the initial message being indexed by k = 0, the next message by 
k= 1, etc.); CINR[fc]is a linear measurement of CINR (derived by any mechanism which delivers the 
prescribed accuracy) for message k\ and ol ?lS% is an averaging parameter specified by the BS. 

To solve for the standard deviation, the expectation-squared statistic shall be updated using Equation (147). 
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*cinrM - 



|CINR[0]| 2 * = 0 (14?) 

(l-a a v g )4iNR^-n + a avg |CINR[/:]| 2 *>0 



and the result applied to 

*CINRdB = 5I °g(|^CINR^]-(AciNRm) 2 |) dB (148) 

8.4.12 Transmitter requirements 

8.4.12.1 Transmit power level control 

The transmitter shall support monotonic power level control of 45 dB (30 dB for license-exempt bands) 
minimum with a minimum step size of 1 dB and a relative accuracy of ± 0.5 dB. 

8.4.12.2 Transmitter spectral flatness 

The average energy of the constellations in each of the n spectral lines shall deviate no more than indicated 
in Table 335. The absolute difference between adjacent subcarriers shall not exceed 0.1 dB, excluding 
intentional boosting or suppression of subcarriers and PAPR reduction subchannels are not allocated. 



Table 335 — Spectral flatness 



Spectral lines 


Spectral flatness 


Spectral lines from to -1 and +1 to N used l4 


±2 dB from the measured energy averaged 
over all active tones 


Spectral lines from -N used /2 to -N used /4 and 
1 +N med l4 to N US J2 


+2A-4 dB from the measured energy averaged 
over all N med active tones 



This data shall be taken from the channel estimation step. 
8.4.12.3 Transmitter constellation error and test method 

To ensure that the receiver SNR does not degrade more than 0.5 dB due to the transmitter SNR, the relative 
constellation RMS error, averaged over subcarriers, OFDMA frames, and packets, shall not exceed a burst 
profile dependent value according to Table 336. 

Table 336 — Allowed relative constellation error versus data rate 



Burst type 


Relative constellation error 
(dB) 


QPSK-1/2 


16.4 


QPSK-3/4 


18.2 


16-QAM-1/2 


23.4 
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Table 336— Allowed relative constellation error versus data rate 



Burst type 


Relative constellation error 
(dB) 


16-QAM-3/4 


25.2 


64-QAM-2/3 


29.7 


64-QAM-3/4 


31.4 



All measurement errors taken together shall be 10 dB less than the required noise level, i.e., if a specification 
is TX S/N = 10 dB, the measurement S/N should be at least 20 dB. For all PHY modes, measurements shall 
be taken with all nonguard subcarriers active and no PAPR reduction subchannels used. 

The sampled signal shall be processed in a manner similar to an actual receiver, according to the following 
steps, or an equivalent procedure (IEEE Std 802.11a-1999 [B29]): 

a) Start of frame shall be detected. 

b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing 
(with one sample resolution) shall be established. 

c) Coarse and fine frequency offsets shall be estimated. 

d) The packet shall be de-rotated according to estimated frequency offset. 

e) The complex channel response coefficients shall be estimated for each of the subcarriers. 

f) For each of the data OFDMA symbols: transform the symbol into subcarrier received values, 
estimate the phase from*the pilot subcarriers, de-rotate the subcarrier values according to estimated 
phase, and divide each subcarrier value with a complex estimated channel response coefficient. 

g) For each data-carrying subcarrier, find the closest constellation point and compute the Euclidean 
distance from it. 

h) Compute the RMS average of all errors in a packet, given by Equation (149). 



Error 



RMS 



N f Z 



i = 1 



N 



FFT 



(I(ijjc) - I 0 (ij,k)) 2 + (GOV,*) - Q 0 (ijJc)) 2 



j = 1 jk = 1 



P 0 ' L P ' N FFT 



N. 



(149) 



7 



where 



L P is the length of the packet, 

N f is the number of frames for the measurement, 

(I 0 (ij,k), Qo (tiX)) denotes the ideal symbol point of the i-th frame,y-th OFDMA symbol of the frame, 

k-th subcarrier of the OFDMA symbol in the complex plane, 
fl(ij,k), Q(i j,k)) denotes the observed point of the i-th frame, j-th OFDMA symbol of the frame, 
A:-th is the subcarrier of the OFDMA symbol in the complex plane, 

p 0 is the average power of the constellation. 
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8.4.13 Receiver requirements 
8.4.13.1 Receiver sensitivity 

The BER shall be less than 10" 6 at the power levels shown in Table 337 for standard message and test condi- 
tions. If the implemented bandwidth is not listed, then the values for the nearest smaller listed bandwidth 
shall apply. The minimum input levels are measured as follows: 

— At the antenna connector or through a calibrated radiated test environment. 

— Using the defined standardized message packet formats. 

— Using an AWGN channel. 



Table 337— Receiver minimum input level sensitivity (dBm) 



Bandwidth 


QPSK 


16-QAM 


64-QAM 


(MHz) 


1/2 


3/4 


1/2 


3/4 


2/3 


3/4 


1.5 


-91 


-89 


-84 


-82 


-78 


-76 


1.75 


-90 


-87 


-83 


-81 


-77 


-75 


3 


-88 


-86 


-81 


-79 


-75 


-73 


3.5 


-87 


-85 


-80 


-78 


-74 


-72 


5 


-86 


-84 


-79 


-77 


-72 


-71 


6 


-85 


-83 


-78 


-76 


-72 


-70 


7 


-84 


-82 


-77 


-75 


-71 


-69 


10 


-83 


-81 


-76 


-74 


-69 


-68 


12 


-82 


-80 


-75 


-73 


-69 


-67 


14 


-81 


-79 


-74 


-72 


-68 


-66 


20 


-80 


-78 


-73 


-71 


-66 


-65 



Table 337 (as well as Table 336) are derived assuming 5 dB implementation loss, a Noise Figure of 7 dB, 
and receiver SNR and E^/Nq values as listed in Table 338. 



Table 338— Receiver SNR and E^N Q assumptions 



Modulation 


(dB) 


Coding rate 


Receiver SNR 
(dB) 


QPSK 


10.5 


1/2 


9.4 


3/4 


11.2 
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Table 338— Receiver SNR and EJNq assumptions 



Modulation 


(dB) 


Coding rate 


Receiver SNR 
(dB) 


16-QAM 


14.5 


1/2 


16.4 


3/4 


18.2 


64-QAM 


19.0 


2/3 


22.7 


3/4 


24.4 



Test messages for measuring Receiver Sensitivity shall be based on a continuous stream of MAC PDUs, 
each with a payload consisting of a R times repeated sequence S morfu/ ^ n . For each modulation, a different 
sequence applies: 

S QPSK = [0xE4, OxB 1 , OxEl , 0xB4] 

S 16QAM = [0xA8, 0x20, 0xB9, 0x31, OxEC, 0x64, OxFD, 0x75] (150) 

S 64QAM = [0xB6, 0x93, 0x49, 0xB2, 0x83, 0x08, 0x96, 0x11, 0x41, 0x92, 0x01, 0x00, 
OxBA, 0xA3, 0x8A, 0x9A, 0x21, 0x82, 0xD7, 0x15, 0x51, 0xD3, 0x05, 
0x10, OxDB, 0x25, 0x92, 0xF7, 0x97, 0x59, 0xF3, 0x87, 0x18, OxBE, 
0xB3, OxCB, 0x9E, 0x31, 0xC3, OxDF, 0x35, 0xD3, OxFB, 0xA7, 
0x9 A, OxFF, 0xB7, OxDB] 



For each mandatory test message, the (R£ moduUltion ) tuples that shall apply are: 

Short length test message payload (288 data bytes): (12,Sq PS k\ (36J>l6-QAAf)> (6,S 64 _q AM ) 

Mid length test message payload (864 data bytes): (216,Sq PSK ), (10%,S 16 .q AM ), 

Long length test message payload (1536 data bytes): (384,5gp 5A: ), (192,5 i6 . eAM ), (32,S 64 _q AM ) 

The test condition requirements are as follows: 

V 

— Ambient room temperature 

— Shielded room 

— Conducted measurement at the RF port if available 

— Radiated measurement in a calibrated test environment if the antenna is integrated 

— CC FEC is enabled 

The test shall be repeated for each test message length and for each (/?,5 madM /^ n ) tuple as identified above, 
using the mandatory FEC scheme. The results shall meet or exceed the sensitivity requirements set out in 
Table 337. 

8.4.13.2 Receiver adjacent and alternate channel rejection 

The adjacent channel rejection and alternate channel rejection shall be measured by setting the desired 
signal's strength 3 dB above the rate dependent receiver sensitivity (see Table 337) and raising the power 
level of the interfering signal until the specified error rate is obtained. The power difference between the 
interfering signal and the desired channel is the corresponding adjacent channel rejection. The interfering 
signal in the adjacent channel shall be a conforming OFDM A signal, not synchronized with the signal in the 
channel under test. For nonadjacent channel testing the test method is identical except the interfering 
channel shall be any channel other than the adjacent channel or the co-channel. 
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For the PHY to be compliant, the minimum rejection shall exceed the following: 



Table 339 — Adjacent and nonadjacent channel rejection 



Modulation/coding 


Adjacent channel 
rejection 
(dB) 


Nonadjacent 
channel rejection 
(dB) 


16-QAM-3/4 


11 


30 


64-QAM-2/3 


4 


23 



8.4.13.3 Receiver maximum input signal 

The receiver shall be capable of decoding a maximum on-channel signal of -30 dBm. 

8.4.13.4 Receiver maximum tolerable signal 

The receiver shall tolerate a maximum signal of 0 dBm without damage. 
8.4.14 Frequency control requirements 

8.4.14.1 Center frequency and symbol clock frequency tolerance 

At the BS, the transmitted center frequency, receive center frequency, and the symbol clock 
frequency shall be derived from the same reference oscillator. At the BS, the reference frequency accuracy 
shall be better than ±2*1 0" 6 . 

At the SS, both the transmitted center frequency and the symbol clock frequency shall be synchronized to 
the BS with a tolerance of maximum 2% of the subcarrier spacing. 

For Mesh capable devices, all device frequencies shall be accurate to within ±20*10" 6 and achieve 
synchronization to its neighboring nodes with a tolerance of maximum 3% of the subcarrier spacing. 

During the synchronization period, the SS shall acquire frequency synchronization within the specified 
tolerance before attempting any uplink transmission. During normal operation, the SS shall track the 
frequency changes and shall defer any transmission if synchronization is lost. 

8.5 WirelessHUMAN specific components 
8.5.1 Channelization 

The channel center frequency shall follow Equation (151): 

Channel center frequency (MHz) = 5000 + 5 n ch (151) 

where n ch = 0,1, ...199 is the Channel Nr. This definition provides an 8-bit unique numbering system for all 
channels, with 5 MHz spacing, from 5 GHz to 6 GHz. This provides flexibility to define channelization sets 
for current and future regulatory domains. The set of allowed channel numbers is shown in Table 340 for 
two regulatory domains. The support of any individual band in the table is not mandatory, but all channels 
within a band shall be supported. 
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Figure 264 depicts the 20 MHz channelization scheme listed in Table 340. Channelization has been defined 
to be compatible with IEEE Std 802.1 la-1999 for interference mitigation purposes, even though this results 
in less efficient spectrum usage in the middle Unlicensed National Information Infrastructure (U-NII) band. 



Table 340— Channelizations 



Regulatory 
domain 


Band 

(GHz) 


Channelization (MHz) 


20 


1U 


USA 


U-NII middle 
5.25-5.35 


56, 60, 64 


55,57, 59,61,63, 65, 67 


U-NII upper 
5.725-5.825 


149, 153, 157, 
161, 165 a 


148, 150, 152, 154, 156, 
158, 160, 162, 164 a ,166 a 


Europe 


CEPT band B b 
5.47-5.725 


100, 104, 108, 
112, 116, 120, 
124, 128, 132, 
136 


99, 101, 103, 105, 107, 
109, 111, 113, 115, 117, 
119, 121, 123, 125, 127, 
129, 131, 133, 135, 137 


CEPT band C b 
5.725-5.875 


148, 152, 156, 
160, 164, 168 


147, 149, 151, 153, 155, 
157, 159, 161, 163, 165, 
167, 169 | 



b Current applicable regulations do not allow this standard to be operated in the 
indicated band. 




U-NII middle and upper band 




5480 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 



CEPT, 5 GHz, band B 




5720 5740 5760 5780 5800 5820 5840 5860 
CEPT, 5 GHz, band C 

Figure 264— Channelization, 20 MHz 
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8.5.2 Transmit spectral mask 

The transmitted spectral density of the transmitted signal shall fall within the spectral mask as shown 
Figure 265 and Table 341. The measurements shall be made using 100 kHz resolution bandwidth and a 30 
kHz video bandwidth. The 0 dBr level is the maximum power allowed by the relevant regulatory body. 

dBr 

0 I 1 




Figure 265— Transmit spectral mask (see Table 341) 



Table 341— Transmit spectral mask parameters 



Channelization 
(MHz) 


A 


B 


C 


D 


20 


9.5 


10.9 


19.5 


29.5 


10 


4.75 


5.45 


9.75 


14.75 
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9. Configuration 

9.1 SS IP addressing 

9.1.1 DHCP fields used by the SS 

The following fields shall be present in the DHCP request from the SS and shall be set as described below 
and encoded as per IETF RFC 2131: 

a) The hardware type (htype) shall be set to 1 (Ethernet). 

b) The hardware length (hlen) shall be set to 6. 

c) The client hardware address (chaddr) shall be set to the 48-bit MAC address associated with the RF 
interface of the SS. 

d) The "client identifier" option shall be included, with the hardware type set to 1, and the value set to 
the same MAC address as the chaddr field. 

e) The "parameter request list" option shall be included. The option codes that shall be included in the 
list are: 

1) Option code 1 (Subnet Mask) 

2) Option code 2 (Time Offset) 

3) Option code 3 (Router Option) 

4) Option code 4 (Time Server Option) 

5) Option code 7 (Log Server Option) 

6) Option code 60 (Vendor Class Identifier)— A compliant SS shall send the following ASCII 
coded string in Option code 60: "802.16." 

The following fields are expected in the DHCP response returned to the SS. The SS shall configure itself 
based on the DHCP response. 

a) The IP address to be used by the SS (yiaddr). 

b) The IP address of the TFTP server for use in the next phase of the bootstrap process (siaddr). 

c) If the DHCP server is on a different network (requiring a relay agent), then the IP address of the. 
relay agent (giaddr). 

NOTE — This may differ from the IP address of the first hop router. 

d) The name of the SS configuration file to be read from the TFTP server by the SS (file). 

e) The subnet mask to be used by the SS (Subnet Mask, option 1). 

f) The time offset of the SS from UTC (Time Offset, option 2). This is used by the SS to calculate the 
local time for use in time- stamping error logs. 

g) A list of addresses of one or more routers to be used for forwarding SS-originated IP traffic (Router 
Option, option 3). The SS is not required to use more than one router IP address for forwarding. 

h) A list of time servers (IETF RFC 868) from which the current time may be obtained (Time Server 
Option, option 4). 

i) A list of S YSLOG servers to which logging information may be sent (Log Server Option, option 7). 
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9.2 SS Configuration file 

9.2.1 SS binary configuration file format 

The SS-specific configuration data shall be contained in the SS configuration file that is downloaded to the 
SS via TFTP. It shall consist of a number of configuration settings (1 per parameter), each in a TLV encoded 
form (see Clause 11). Note that SSs are not required to need a configuration file. In this case, the 
configuration file name will not be present in the DHCP response. 

Configuration settings are divided into three types as follows: 

— Standard configuration settings that shall be present 

— Standard configuration settings that may be present 

— Vendor-specific configuration settings 

SSs shall be capable of processing all standard configuration settings. SSs shall ignore any configuration 
setting in the configuration file that it cannot interpret. To allow uniform management of SSs conformant to 
this specification, conformant SSs shall support a 8192 byte configuration file at a minimum. 

Integrity of the configuration file information is provided by the SS message integrity check (MIC). The SS 
MIC is a digest that ensures the data sent from the provisioning server were not modified en route. This is 
not an authenticated digest (i.e., it does not include any shared secret). 

The SS MIC shall immediately be followed by the End of Data marker equal to OxFF. 

In case the file is a non-integer number of 32-bit words, the file shall be padded with zeros until the next 
32-bit boundary. 

The file structure is shown in Figure 266: 



Configuration 


Configuration 




Configuration 


SSMIC 


End of Data 


Pad (optional) 


Setting 1 


Setting 2 




Setting n 




OxFF 





Figure 266— Configuration file structure 



9.2.2 Configuration file settings 

The following configuration settings shall be included in the configuration file and shall be supported by all 
SSs: 

a) SS MIC Configuration Setting 

b) TFTP Server Timestamp 

The following configuration settings may be included in the configuration file and if present shall be 
supported by all SSs: 

a) Software Upgrade Filename Configuration Setting (see 1 1 .2.2) 

b) Software Server IP Address (see 1 1 .2.3) 

c) Authorization Node IP Address (11.2.5, Mesh only) 

d) Registration Node IP Address (1 1 .2.6, Mesh only) 

e) Provisioning Node IP Address (1 1 .2.7, Mesh only) 

f) Vendor-specific configuration settings 
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9.2.3 Configuration file creation 

The sequence of operations required to create the configuration file is as shown in Figure 267, Figure 268, 
and Figure 269. 

a) Create the TLV entries for all the parameters required by the SS. 



type, length, value for parameter 1 



type, length, value for parameter 2 



type, length, value for parameter n 



Figure 267— Create TLV entries for parameters required by the SS 

b) Calculate the SS MIC configuration setting as defined in 9.2.3.1 and add to the file following the last 
parameter using code and length values defined for this field. 



type, length, value for parameter 1 



type, length, value for parameter 2 



type, length, value for parameter n 



type, length, value for SS MIC 



Figure 268— Add SS MIC 

c) Add the end of data marker and pad with zeros to next 32-bit boundary if necessary. 



type, length, value for parameter 1 



type, length, value for parameter 2 



type, length, value for parameter n 



type, length, value for SS MIC 



end of data marker pad (optional) 



Figure 269— Add end of data marker and pad 
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9.2.3.1 SS MIC calculation 

The SS MIC configuration setting shall be calculated by performing a SHA-1 digest over the bytes of the 
configuration setting fields. It is calculated over the bytes of these settings as they appear in the TFTPed 
image, without regard to TLV ordering or contents. There are two exceptions to this disregard of the 
contents of the TFTPed image: 

— The bytes of the SS MIC TLV itself are omitted from the calculation. This includes the type, length, 
and value fields. 

— On receipt of a configuration file, the SS shall recompute the digest and compare it to the SS MIC 
configuration setting in the file. If the digests do not match, then the configuration file shall be 
discarded. 
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10. Parameters and constants 
10.1 Global values 

The BS and SS shall meet the timing requirements contained in Table 342. 



Table 342— Parameters and constants 



System 


Name 


Time reference 


Minimum 
value 


Default 
value 


Maximum 
value 


BS 


DCD Interval 


Time between transmission of 
DCD messages 






10 s 1 


BS 


UCD Interval 


Time between transmission of 
UCD messages 






10 s 


BS 

• 


UCD Transition 


The time the BS shall wait after 
repeating a UCD message with 
an incremented Configuration 
Change Count before issuing a 
UL-MAP message referring to 
Uplink J5urst_Profiles defined 
in that UCD message 


2 MAC 
frames 






BS 


DCD Transition 


The time the BS shall wait after 
repeating a DCD message with 
an incremented Configuration 
Change Count before issuing a 

\Ji-i -ivir\r message iciciiiiig iu 

Down link_Burst_Pro files 
defined in that DCD message 


2 MAC 
frames 






BS 


Max MAP Pending 


Maximum validity of map 






End of next 
frame 


BS 


Initial 

Rnncifity Interval 
IXalJgJIltJ, lillGlVdl 


Time between Initial Ranging 

rp»(rinnc nccinnpH K\/ thf» R^k 
ICglUIlo daMgllCU Uy II1C DO 






2s 


BS 


CLK-CMP Interval 


Time between the clock com- 

nnre* m f 1 Q c 1 1 rt* m p n f c iic^H frvr t\t(* 
palC HlCaoUICJIlCIlld UbCU U1C 

generation of CLK-CMP 
messages. 


50 ms 


50 ms 


50 ms 


SS 


Lost DL-MAP 
Interval 


Time since last received 
DL-MAP message before 
downlink synchronization is 
considered lost 






600 ms 


SS 


LostUL-MAP 
Interval 


Time since last received 
UL-MAP message before 
uplink synchronization is 
considered lost 






600 ms 


SS 


Contention Ranging 
Retries 


Number of retries on contention 
Ranging Requests 


16 






SS, BS 


Invited Ranging 
Retries 


Number of retries on inviting 
Ranging Requests 


16 






SS 


Request Retries 


Number of retries on bandwidth 
allocation requests 


16 
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Table 342— Parameters and constants (continued) 



System 


Name 


Time reference 


Minimum 
value 


Default 
value 


Maximum 
value 


SS 


Registration Request 
Retries 


Number of retries on 
registration requests 


3 






BS 


Tproc 


Time provided between arrival \ 
of the last bit of a UL-MAP at 
an SS and effectiveness of that 
map 


SC: 

200 |xs 
OFDM: 

1 ms 
OFDMA: 

10 

OFDMA 
symbols 






BS 


SS Ranging Response 
Processing Time 


Time allowed for an SS 
following receipt of a ranging 
response before it is expected to 
reply to an invited ranging 
request 


10 ms 






SS, BS 


Minislot size 
CSC/SCa onlv) 


Size of minislot for uplink 
transmission. Shall be a power 
of 2 (in units of PS) 


IPS 






SS, BS 


DSx Request Retries 


Number of Timeout Retries on 
DSA/DSC/DSD Requests 




3 




SS, BS 


DSx Response Retries 


Number of Timeout Retries on . 
DSA/DSC/DSD Responses 




3 




SS 


TFTP Backoff Start 


Initial value for TFTP backoff 


Is 








TFTP Rarkoff End 


Last value for TFTP backoff 


16s 






SS 


TFTP Request Retries 


Number of retries on TFTP 


16 






SS 


TFTP Download 

IVCLl ICa 


Number of retries on entire 
TFTP downloads 


3 






SS 


TFTP Wait 


The duration between two 
consecutive TFTP retries 


2 min 






SS 


Time of Day Retries 


Number of Retries per Time of 
Day Retry Period 


3 






SS 


Time of Day Retry 
Period 


Time period for Time of Day 
retries 


5 min 






SS 


Tl 


Wait for DCD timeout 






5 * DCD 
interval 
maximum 
value 


SS 


T2 


Wait for broadcast ranging 
timeout 






5 * ranging 
interval 


SS 


T3 


Ranging Response reception 
timeout following the 
transmission of a Ranging 
Request 




200 ms 


200 ms 
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Svstpm 


Name 


A IHlC ICLClCIltv 


Minimum 

ivi nil iiium 

value 


ueiduii 
value 


Maximum 
value 


CP 


14 


Wait for unicast ranging 
opportunity. If the pending- 
until-complete field was used 
earlier by this SS, then the value 
of that field shall be added to 
this interval. 


30 s 




35 s 


BS 


T5 


Wait for Uplink Channel 
Change response 






2s 


SS 


T6 


Wait for registration response 






3s 


SS, BS 


T7 


Wait for DSA/DSC/DSD 
Response timeout 






1 s 


SS, BS 


T8 


Wait for DSA/DSC 
Acknowledge timeout 






300 ms 


BS 


T9 


Registration Timeout, the time 
allowed between the BS 
sending a RNG-RSP (success) 
to an SS, and receiving a 
SBC-REQ from that same SS 


300 ms 


300 ms 




SS, BS 


T10 


Wait for Transaction End 
timeout 






3s 


CO 

SS 


T12 


Wait for UCD descriptor 






5 * UCD 
Interval 
maximum 
value 


BS 


T13 


The time allowed for an SS, 
following receipt of a REG-RSP 
message to send a TFTP-CPLT 
message to the BS 


15 min 


15 min 




SS 


T14 


Wait for DSX-RVD Timeout 






200 ms 


BS 


T15 


Wait for MCA-RSP 


20 ms ' 


20 ms 




SS 


T16 


Wait for bandwidth request 
grant 


10 ms 




service QoS 
dependent 


BS 


T17 


Time allowed for SS to com- 
plete SS Authorization and Key 
Exchange 


5 min 


5 min 




SS 


T18 


Wait for SBC-RSP 
timeout 




50 ms 


«T9 , 


SS 


T19 


Time DL-channel remains 
unusable 








SS 


T20 


Time the SS searches for 
preambles on a given channel 


2 MAC 
frames 






SS 


T21 


Time the SS searches for 
DL-MAP on a given channel 






10s 


SS, BS 


T22 


Wait for ARQ-Reset 






0.5 s 
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Table 342— Parameters and constants (continued) 



System 


Name 


Time reference 


Minimum 
value 


Default 
value 


Maximum 
value 


Mesh 
node 


T23 


Network Entry: Detect network 


1 s 






Mesh 
node 


T24 


Network Entry: Accumulate 
MSH-NCFG messages 




120 s 




Mesh 
node 


T25 


Network Entry: Wait for 
MSH-NENT/MSH-NCFG 




1 s 




SS 


SBC Request Retries 


Number of retries on SBC 
Request 


3 


3 


16 


SS 


TFTP-CPLT Retries 


Number of retries on TFTP- 
CPLT 


3 


3 


16 


SS 


T26 


Wait for TFTP-RSP 


10 ms 


200 ms 


200 ms 


BS 


T27 as Idle Timer 


Maximum time between unicast 
grants to SS when BS believes 
SS uplink transmission quality 
is good enough 


SS 

Ranging 
Response 
Processing 
Time 






BS 


T27 as Active Timer 


Maximum time between unicast 
grants to SS when BS believes 
SS uplink transmission quality 
is not good enough 


SS 

Ranging 
Response 
Processing 
Time 






SS 


SS downlink manage- 
ment message 
processing time 


Max. time between reception of 
Fast Power Control manage- 
ment message and compliance 
to its instructions by SS 






200 \is 

(OFDM 

only) 



10.2 PKM parameter values 

Table 343 defines the ranges and default values for the PKM configuration and operational parameters. 

For the purposes of protocol testing, it is useful to run the privacy protocol with timer values well below the 
low end of the operational ranges. The shorter timer values "speed up" privacy's clock, causing privacy 
protocol state machine events to occur far more rapidly than they would under an "operational" 
configuration. While privacy implementations need not be designed to operate efficiently at this accelerated 
privacy pace, the protocol implementation should operate correctly under these shorter timer values. 
Table 344 provides a list of shortened parameter values that are likely to be employed in protocol 
conformance and certification testing. 

The TEK Grace Time shall be less than half the TEK lifetime. 
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Table 343 — Operational ranges for privacy configuration settings 



System 


Name 


Description 


Minimum 
value 


Default 
value 


Maximum 
value 


BS 


AK Lifetime 


Lifetime, in seconds, BS assigns 
to new AK 


1 day 
(86 400 s) 


7 days 
(604 800 s) 


70 days 

(6 048 000 s) 


BS 


TEK Lifetime 


Lifetime, in seconds, BS assigns 
to new TEK 


30 min 
(1800 s) 


12 h 

(43 200 s) 


7 days 
(604 800 s) 


SS 


Authorize Wait 
Timeout 


Auth Req retransmission inter- 
val from Auth Wait state 


2s 


10 s 


30 s 


ss 


Reauthorize Wait 
Timeout 


Auth Req retransmission interval 
from Reauth Wait state 


2s 


10s 


30 s 


SS 


Authorization 
Grace Time 


Time prior to Authorization expi- 
ration SS begins reauthorization 


5 min 
(300 s) 


10 min 
(600 s) 


35 days 

(3 024 000 s). 


ss 


Operational Wait 
Timeout 


Key Req retransmission interval 
from Op Wait state 


1 s 


1 s 


10s 


ss 


Rekey Wait 
Timeout 


Key Req retransmission interval 
from Rekey Wait state 


1 s 


1 s 


10s 


ss 


TEK Grace Time 


Time prior to TEK expiration SS 
begins rekey ing 


5 min 
(300 s) 


1 h 

(3600 s) 


3.5 days 
(302 399 s) 


ss 


Authorize Reject 
Wait Timeout 


Delay before resending Auth 
Request after receiving Auth 
Reject 


10 s 


60s 


10 min i 
(600 s) 



Table 344— Values for privacy configuration setting for protocol testing 



Parameter 


Shortened value 


AK Lifetime 


5 min (300 s) 


TEK Lifetime 


3 min (180 s) 


Authorization Grace Time " 


1 min (60 s) 


TEK Grace time 


1 min (60 s) 



10.3 PHY-specific values 

10.3.1 WirelessMAN-SC parameter and constant definitions 

10.3.1.1 PS 

For the WirelessMAN-SC PHY, a PS is the duration of four modulation symbols at the symbol rate of the 
downlink transmission. 

10.3.1.2 Symbol rate 

The symbol rate shall be in the range 10-44.8 MBd, in increments of 100 kBd. 
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10.3.1.3 Uplink center frequency 

The uplink center frequency shall be a multiple of 250 kHz. 

10.3.1.4 Downlink center frequency 

The downlink center frequency shall be a multiple of 250 kHz. 

10.3.1.5 Tolerated poll jitter 

For the 10-66 GHz PHY, the minimum value of the Tolerated Poll Jitter (see 11.13.13) shall be 3000 us. 

1 0.3.1 .6 Allocation Start Time 

Unit of Allocation Start Time shall be minislots from the start of the downlink frame in which the UL-MAP 
message occurred. 

10.3.1.7 Timing Adjust Units 

The timing adjust units shall be 1/4 modulation symbols. During periodic ranging, the range of the value of 
this parameter shall be limited to ±2 modulation symbols. 

1 0.3.2 WirelessM AN-SCa parameters and constant definitions 

10.3.2.1 Uplink Allocation Start Time 

Unit of Allocation Start Time shall be PSs from the start of the downlink frame in which the UL-MAP 
message occurred. The minimum value specified for this parameter shall correspond to one frame duration. 

10.3.2.2 PS 

PSs are defined as in Equation (152): 

PS = 4 x Symbol duration ( 152 > 

1 0.3.2.3 Timing adjust units 

The timing adjust units shall be 1/32 modulation symbols. 

10.3.3 WirelessM AN-OFDM parameters and constant definitions 

10.3.3.1 Uplink Allocation Start Time 

Unit of Allocation Start Time shall be PSs from the start of the downlink frame in which the UL-MAP 
message occurred. The minimum value specified for this parameter shall correspond to a point in the frame 
1 ms after the last symbol of the UL-MAP. 

10.3.3.2 PS 

PSs are defined as in Equation (153): 

PS = 4/R (153) 
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10.3.3.3 Timing adjust units 

The timing adjust units shall be 1/F S . 

10.3.4 WirelessMAN-OFDMA parameters and constant definitions 

10.3.4.1 Uplink Allocation Start Time 

Unit of Allocation Start Time shall be PSs from the start of the downlink frame in which the UL-MAP 
message occurred. The minimum value specified for this parameter shall correspond to 10 OFDM A 
symbols. 

10.3.4.2 PS 

PSs are defined as Equation (154): 

PS=4/F S (154) 

10.3.4.3 Timing adjust units 

The timing adjust units shall be 1/F S . 

10.4 Well-known addresses and identifiers 

There are several CIDs defined in Table 345 that have specific meaning. These identifiers shall not be used 
for any other purposes. 



Table 345— CIDs 



cm 


Value 


Description 


Initial ranging 


0x0000 


Used by SS and BS during initial ranging process. 


Basic CID 


0x0001- m 


The same value is assigned to both the PL and UL 
connection. 


Primary management 


m+ 1 - 2m 


The same value is assigned to both the DL and UL 
connection. 


Transport CIDs and 
secondary Mgt CIDs 


2m+ l-0xFEFE 


For the secondary management connection, the same value 
is assigned to both the DL and UL connection. 


AAS initial ranging CID 


OxFEFF 


A BS supporting AAS shall use this CID when allocating a 
Initial Ranging period for AAS devices. 


Multicast polling CIDs 


OxFFOO-OxFFFD 


An SS may be included in one or more multicast polling 
groups for the purposes of obtaining bandwidth via polling. 
These connections have no associated service flow. 


Padding CID 


OxFFFE 


Used for transmission of padding information by SS and 
BS. 


Broadcast CID 


OxFFFF 


Used for broadcast information that is transmitted on a 
downlink to all SS. 
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11. TLV encodings 

The following TLV encodings shall be used for parameters in both the configuration file (Clause 9) and 
MAC Management messages (6.3.2.3). TLV tuples with Type values not specified in this standard or 
specified as "reserved" should be silently discarded. The length of the Type field shall be one byte. 

The format of the Length field shall be per the "definite form" of ITU-T X.690. Specifically, if the actual 
length of the Value field is less than or equal to 127 bytes, then 

— The length of the Length field shall be one byte, 

— The MSB of the Length field shall be set to 0, and 

— The other 7 bits of the Length field shall be used to indicate the actual length of the value field in 
bytes. 

If the length of the Value field is more than 127 bytes, then: 

— The length of the length field shall be one byte more than what is actually used to indicate the length 
of the value field in bytes, 

— The MSB of the first byte of the length field shall be set to 1 , 

— The other 7 bits of the first byte of the length field shall be used to indicate the number of additional 
bytes of the length field (i.e., excluding the first byte), and 

— The remaining bytes (i.e., excluding the first byte) of the length field shall be used to indicate the 
actual length of the value field. 

NOTE— Uniqueness of TLV Type values is assured by identifying the groups of IEEE 802.16 entities (configuration file 
and/or MAC Management messages) that share references to specific TLV encodings. Disjoint collections of TLVs are 
formed that correspond to each such functional grouping. Each set of TLVs that are explicitly defined to be members of 
a compound TLV structure form additional collections. Unique Type values are assigned to the member TLV encodings 
of each collection. 

An additional collection, the Common encodings, is defined that consists of TLV encodings that are referenced by more 
than one of the functional groups. The Type values of the TLV members of this collection are assigned to assure 
uniqueness across all collections. This is the only collection for which global uniqueness is guaranteed. 

In cases where a collection contains TLV encodings that are PHY specification specific, subcollections are formed that 
contain these TLV encodings. Type values assigned to members of each subcollection are assigned such that the values 
are unique within the subcollection and with non-PHY specification specific members of the collection. Type values are 
not unique across PHY-specific subcollections. 

TLV Type values are assigned in accordance with the following rules: 

— Common encodings start at 149, subsequent values are assigned in descending order. 

— For individual collections, non-PHY specification specific encodings start at 1, subsequent values are assigned 
in ascending order. 

— For individual collections, PHY specification specific encodings start at 150, subsequent values are assigned in 
ascending order. 
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11.1 Common encodings 

Common TLV fields and their associated type codes are presented in Table 346. 



Table 346— Type values for common TLV encodings 



Type 


Name 


149 


HMAC tuple 


148 


MAC version encoding 


147 


Current transmit power 


146 


Downlink service flow 


145 


Uplink service flow 


144 


Vendor ID encoding 


143 


Vendor- specific information 



11.1.1 Current transmit power 

The parameter indicates the transmitted power used for the burst which carried the message. The parameter 
is reported in dBm and is quantized in 0.5 dBm steps ranging from -64 dBm (encoded 0x00) to 63.5 dBm 
(encoded OxFF). Values outside this range shall be assigned the closest extreme. The parameter is only 
applicable to systems supporting the SCa, OFDM, or OFDMA PHY specifications. 



Type 


Length 


Value 


Scope 


147 


1 


Current transmitted power 


SBC-REQ, 
REP-RSP 



When included in an SBC-REQ message, the TLV is encapsulated in the Physical supported parameters 
compound TLV 

11.1.2 HMAC tuple 

This parameter contains the HMAC Key Sequence Number concatenated with an HMAC-Digest used for 
message authentication. The HMAC Key Sequence Number is stored in the four least significant bits of the 
first byte of the HMAC Tuple, and the most significant four bits are reserved. The HMAC-Tuple attribute 
format is shown in Table 347 and Table 348. 



Table 347— HMAC Tuple definition 



Type 


Length 


Value 


Scope 


149 


21 


See Table 348 


DSx-REQ, DSx-RSP, 
DSx-ACK, REG-REQ, 
REG-RSP, RES-CMD, 
DREG-CMD, TFTP-CPLT 
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Table 348— HMAC Tuple value field 



Field 


Length 


Notes 


reserved 


4 bits 




HMAC Key Sequence Number 


4 bits 




HMAC-Digest 


160 bits 


HMAC with SHA-1 



11.1.3 MAC version encoding 

This parameter specifies the version of IEEE 802.16 to which the message originator conforms. If the MAC 
version values exchanged between a BS and SS during network entry and initialization differ, one of the 
following actions are taken: 

— BS version > SS version ==> SS performs normal operations, but BS communicates with the SS per the 

version level specified by the SS. 

— BS version < SS version ==> SS performs normal operations, but does so in conformance with the ver- 

sion level specified by BS. If backward-compatibility is not supported, SS 
disables any attempt for uplink transmission to BS. 



Type 


Length 


Value 


Scope 


148 


1 


Version number of 802.16 supported on this channel. 
1: Indicates conformance with IEEE Std 802.16-2001 
2: Indicates conformance with IEEE Std 802.16c-2002 

and its predecessors 
3: Indicates conformance with IEEE Std 802.16a-2003 

and its predecessors 
4: Indicates conformance with IEEE Std 802.16-2004 
5-255: reserved 


PMP: DCD, 

RNG-REQ 

MESH: REG-REQ, 
REG-RSP 



11.1 .4 Service flow descriptors 

Information regarding the attributes of an uplink or downlink service flow shall be encapsulated in a 
compound structure identified by the appropriate TLV Type value. The contents of the compound structure 
are defined in 11.13. 



Type 


Length 


Value 


Scope 


146 


variable 


Compound: Downlink service flow 


DSx-REQ, DSx-RSP, DSx-ACK 


145 


variable 


Compound: Uplink service flow 


DSx-REQ, DSx-RSP, DSx-ACK 



11.1.5 Vendor ID encoding 

The value field contains the vendor identification specified by the 3-byte, vendor-specific organizationally 
unique identifier of the SS or BS MAC address. 
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When used as a subfield of the TLVs Vendor-specific information, Vendor-specific QoS parameters, Vendor- 
specific classifier parameters, Vendor-specific PHS parameters, or Software upgrade descriptors, the Vendor 
ID encoding identifies the Vendor ID of the SSs that are intended to use this information. A vendor ID used 
in a Registration Request shall be the Vendor ID of the SS sending the request. A vendor ID used in a 
Registration Response shall be the Vendor ID of the BS sending the response. 



Type 


Length 


Value 


Scope 


144 


3 


vl, v2, v3 


REG-REQ (see 6.3.2.3.7), 
REG-RSP (see 6.3.2.3.8) 
DSx-REQ, DSx-RSP, DSx-ACK, 
Configuration File 



11.1 .6 Vendor-specific information 

Vendor-specific information for SSs, if present, shall be encoded in the vendor-specific information field 
(VSIF) (type 143) using the Vendor ID field (11.1.5) to specify which tuples apply to which vendor's 
products. The Vendor ID shall be the first TLV embedded inside VSIF. If the first TLV inside VSIF is not a 
Vendor ID, then the TLV shall be discarded. 

This configuration setting may appear multiple times. The same Vendor ID may appear multiple times. This 
configuration setting may be nested inside a Packet Classification Configuration Setting, a Service How 
Configuration Setting, or a Service Flow Response. However, there shall not be more than one Vendor ID 
TLV inside a single VSIF. 



Type 


Length 


Value 


143 


variable 


Per vendor definition 



Example: 

Configuration with vendor A specific fields and vendor B specific fields: 

VSIF (143) + n (number of bytes inside this VSIF) 
8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor A 
Vendor A Specific Type #1 + length of the field + Value #1 
Vendor A Specific Type #2 + length of the field + Value #2 

VSIF (143) + n (number of bytes inside this VSIF) 

8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor B 

Vendor B Specific Type + length of the field + Value 
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11.2 Configuration file encodings 

These settings are found only in the configuration file. They shall not be forwarded to the BS in the 
Registration Request. 

11.2.1 SS MIC configuration setting 

This value field contains the SS MIC code. This is used to detect unauthorized modification or corruption of 
the configuration file. 



Type 


Length 


Value 


1 


20 


dl d2 d20 



11.2.2 Software upgrade descriptors 

This field defines the parameters associated with software upgrades. It is composed of one or more upgrade 
descriptors. An upgrade descriptor is defined by the set of all encapsulated tags defined in 11.2.2.1 through 
11.2.2.4, occurring in order in the TFTP file. A new upgrade descriptor begins with the occurrence of the 
Vendor ID TLV. 



Type 


Length 


Value 


2 


variable 


Compound 



When a managed SS decodes a descriptor with a matching Vendor ID, Hardware ID, and Software version 
different than the one currently running, it may initiate a TFTP transfer to upgrade its software. 

11.2.2.1 Vendor ID 

This value identifies the managed SS vendor to which the software upgrade is to be applied. Its format and 
value is described in ILLS. 



Type 


Length 


Value 


2.144 


3 


vl,v2, v3 



11.2.2.2 Hardware ID 

This value identifies the hardware version to which the software upgrade is to be applied. This value is 
administered by the vendor identified by the Vendor ID field. 



Type 


Length 


Value 


2.1 


n 


Hardware ID (string) 
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11.2.2.3 Software version 

This value identifies the software version of the software upgrade file. The^ value is administered by the 
vendor identified in the Vendor ID field. It should be defined by the vendor to be. unique with respect to a 
given Hardware ID. 



Type 


Length 


Value 


2.2 


n 


Software version (string) 



11.2.2.4 Upgrade filename 

The filename of the software upgrade file for the managed SS. The filename is a fully qualified directory- 
path name that is in a format appropriate to the server. There is no requirement that the character string be 
null-terminated; the length field always identifies the end of the string. The file is expected to reside on a 
TFTP server identified in a configuration setting option defined in 11.2.3. 



Type 


Length 


Value 


2.3 


n 


Filename 



11 .2.3 Software upgrade TFTP server 

This object is the IP address of the TFTP server on which the software upgrade file for the SS resides. 



Type 


Length 


Value 


3 


4 or 16 


IP Address \ 



11.2.4 TFTP Server Timestamp 

This is the sending time of the configuration file in seconds. The definition of time is as in IETF RFC 868. 



Type 


Length 


Value 


4 


4 


Number of seconds since 00:00 1 January 1900 



NOTE — The purpose of this parameter is to prevent replay attacks with old configuration files. 
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11.2.5 Authorization Node 

The Authorization Node parameter contains the IP address of the Authorization Node. 
Applicable only to Mesh mode. 



Type 


Length 


Value 


5 


4 or 16 


IP Address 



11.2.6 Registration Node 

The Registration Node parameter contains the IP address of the Registration Node. 
Applicable only to Mesh mode. 



Type 


Length 


Value 


6 


4 or 16 


IP Address j 



11.2.7 Provisioning Node 

The Provisioning Node parameter contains the IP address of the Provisioning Node. 
Applicable only to Mesh mode. 



Type 


Length 


Value 


7 


4 or 16 


IP Address 



11.3 UCD management message encodings 

The UCD message encodings are specific to the UCD message (see 6.3.2.3.3). 
11.3.1 UCD channel encodings 

UCD channel encodings shared across PHY specifications are provided in Table 349. 



Table 349— UCD common channel encodings 



Name 


Type 
(1 byte) 


Length 


Value 


Uplink_Burst_Profile 


1 




May appear more than once (see 6.3.2.3.3). The length is the number 
of bytes in the overall object, including embedded TLV items. 


Contention-based 
reservation timeout 


2 


1 


Number of UL-MAPs to receive before contention-based reservation 
is attempted again for the same connection. 
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Table 349— UCD common channel encodings (continued) 



Name 


Type 
(1 byte) 


Length j 


Value 


Bandwidth request 
opportunity size 


3 


2 


Size (in units of PS) of PHY payload that SS may use to format and 
transmit a bandwidth request message in a contention request oppor- 
tunity. The value includes all PHY overhead as well as allowance for 
the MAC data the message may hold. 


Ranging request 
opportunity size 


4 


2 


Size (in units of PS) of PHY bursts that an SS may use to transmit a 
RNG-REQ message in a contention ranging request opportunity. The 
value includes all PHY overhead as well as the maximum SS/BS 
round trip propagation delay. 


Frequency 


5 


4 


Uplink center frequency (kHz). 



The UCD channel encodings unique to each PHY specifications are provided in Table 350, 
Table 352, and Table 353. 



Table 350— UCD PHY-specific channel encodings — WirelessMAN-SC 



Name 


Type 
(1 byte) 


Length 


Value 


Symbol rate 


150 


2 


Symbol rate, in increments of 10 kBd. 


SSTG 


151 


1 


The time, as measured at the BS and expressed in PSs, between the 
end of an SS burst and the beginning of the subsequent SS burst. The 
SS shall take this into account when determining the length of the 
burst. The SSTG consumes the last n PS of the intervals allocated in 
the UL-MAP. That is, UL-MAP entries include the time for a burst's 
ramp down. 


Roll-off factor 


152 


1 


2 = 0.25 

0,1, 3-255 Reserved 


Power adjustment 
rule 


153 


1 


0 = Preserve Peak Power 

1 = Preserve Mean Power 

Describes the power adjustment rule when performing a transition 
from one burst profile to another. 


Minislot Size 


154 


1 


The size n of the minislot for this uplink channel in units of physical 
slots (PSs). Allowable values are n = 2 m , where m is an integer ranging 
from 0 through 7. 


UL channel ID 


155 


1 


The identifier of the uplink channel to which this message refers. This 
identifier is arbitrarily chosen by the BS and is only unique within the 
MAC domain. 
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— WirelessMAN-SCa 



Name 


Type 
(I bvte) 


Length 


Value 


Symbol rate 


150 


2 


Symbol rate, in increments of 10 kBd. 


SSTG 


151 


1 


The time, as measured at the BS and expressed in PSs, between the end 
of an SS burst and the beginning of the subsequent SS burst. The SS 
shall take this into account when determining the length of the burst. The 
SSTG consumes the last n PS of the intervals allocated in the UL-MAP. 
That is, UL-MAP entries accommodate the RxDS burst element, which 
includes time for both ramp down and delay spread to clear the receiver. 


Roll-off factor 


152 


1 


0 = 0.15 1 

1 = 0.18 

2 = 0.25 (default) 
3-255 = Reserved 


Power adjust- 
ment rule 


153 


1 


0 = Preserve Peak Power 

1 = Preserve Mean Power 

Describes the power adjustment rule when performing a transition from 
one burst profile to another. 


Initial Ranging 
SSTG 


154 


1 


The time, as measured at the BS and expressed in PSs, between the end 
of an SS burst and the beginning of a subsequent burst residing in an 
Initial Ranging slot. Or, the time, as measured at the BS and expressed in 
PSs, between the end of burst in an Initial Ranging slot and beginning of 
a subsequent SS burst. 

An SS shall take this into account when determining the length of a burst 
in an Initial Ranging slot. The Initial Ranging SSTG consumes the last n 
PS of the intervals allocated in the UL-MAP. That is, UL-MAP entries 
accommodate the RxDS burst element, which includes time for both 
ramp down and delay spread to clear the receiver. 


Minislot Size 


155 


1 


The size n of the minislot for this uplink channel in units of physical 
slots (PSs). Allowable values are n = 2 m , where m is an integer ranging 
from 0 through 7. 


UL channel ID 


156 


1 


The identifier of the uplink channel to which this message refers. This 
identifier is arbitrarily chosen by the BS and is only unique within the 
MAC domain. 


Table 352— UCD PHY-specific channel encodings — WirelessMAN-OFDM 


Name 


Type 
(1 byte) 


Length 


Value 


Subchannelization 
REQ Region-Full 
Parameters 


150 


1 


Bits 0. . .2 Number of subchannels used by each transmit opportunity \ 
when REQ Region-Full is allocated in subchannelization region, per the 
following enumeration: 
0: 1 Subchannel. 

1: 2 Subchannels. 1 

2: 4 Subchannels. 

3: 8 Subchannels. 

4: 16 Subchannels. 

5-7: Shall not be used. 
Bits 3 . . .7: Number of OFDM symbols used by each transmit opportunity 
when REQ Region-Full is allocated in subchannelization region. 


Subchannelization 
focused conten- 
tion codes 


151 


1 


Number of contention codes (C SE ) that shall only be used to request a 

subchannelized allocation. 

Default value 0. Allowed values 0-8. 
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Table 353— UCD PHY-specific channel encodings — WirelessMAN-OFDMA 



Name 


Type 
(1 byte) 


Length 


Value 


Initial ranging codes 


150 


1 


Number of initial ranging CDMA codes. Possible values are 
0-255. a 


Periodic ranging 
codes 


151 


1 


Number of periodic ranging CDMA codes. Possible values are 
0-255. a 


Bandwidth request 
codes 


152 


1 


Number of bandwidth request codes. Possible values are 0-255. 


Periodic ranging 
backoff start 


153 


1 


Initial backoff window size for periodic ranging contention, 
expressed as a power of 2. Range: 0-15 (the highest order bits shall 
be unused and set to 0). 


Periodic ranging 
backoff end 


154 


1 


Final backoff window size for periodic ranging contention, 
expressed as a power of 2. Range: 0-15 (the highest order bits shall 
be unused and set to 0). 


Start of ranging codes 
group 


155 


1 


Indicates the starting number, S, of the group of codes used for this 

uplink. All the ranging codes used on this uplink will be between S 

and ((S+N+M+L) mod 256). Where, 

N is the number of initial-ranging codes 

M is the number of periodic-ranging codes 

L is the number of bandwidth-request codes 

The range of values is 0 < 5 < 255. 


Permutation base 


156 


1 


Determines the ULJDcell parameter for the subcarrier permutation 
to be used on this uplink channel. 


UL allocated 
subchannels bitmap 


157 


9 


This is a bitmap describing the subchannels allocated to the segment 
in the UL, when using the uplink PUSC permutation. The LSB of 
the first byte shall correspond to subchannel 0. For any bit that is not 
set, the corresponding subchannel shall not be used by the SS on that 
segment. 


Optional permutation 
UL Allocated 
subchannels bitmap 


158 


13 


This is a bitmap describing the subchannels allocated to the segment 
in the UL, when using the uplink optional PUSC permutation (see 
8.4.6.2.5). The LSB of the first byte shall correspond to subchannel 
0. For any bit that is not set, the corresponding subchannel shall not 
be used by the SS on that segment. 


BandAMC 
Allocation Threshold 


159 


1 


dB unit 


Band AMC Release 
Threshold 


160 




dB unit 


BandAMC 
Allocation Timer 


161 


1 


Frame unit 


Band AMC Release 
Timer 


162 


1 


Frame unit 


B and Status Reporting 
MAX Period 


163 




Frame unit 


Band AMC Retry 
Timer 


164 


! 


Frame unit 


Safety Channel 
Allocation Threshold 


165 




dB unit 


Safety Channel 
Release Threshold 


166 




dB unit 


Safety Channel 
Allocation Timer 


167 




Frame unit 
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Table 353— UCD PHY-specific channel encodings — WirelessMAN-OFDMA (continued) 



Name 


Type 
(1 byte) 


Length 


Value 


Safety Channel 
Release Timer 


168 


1 


Frame unit 


Bin Status Reporting 
MAX Period 


169 


1 


Frame unit ! 


Safety Channel Retry 
Timer 


170 


1 


Frame unit 


H-ARQ ACK delay 
for UL burst 


171 


1 


1 = one frame offset 

2 = two frames offset 

3 = three frames offset 


CQICH Band AMC- 
Transition Delay 


172 


1 


Frame unit 



^e total number of codes shall be equal or less than 256. 



11.3.1.1 Uplink burst profile encodings 

The uplink burst profile encodings unique to each PHY specification are provided in Table 354, Table 355, 
Table 356, and Table 357. 



Table 354— UCD burst profile encodings— WirelessMAN-SC 



Name 


Type 
(1 byte) 


Length 


Value (variable-length) 


Modulation type 


150 


1 


1=QPSK, 2=16-QAM, 3=64-QAM 


Preamble length 


151 


1 


The number of symbols in the preamble pattern. The preamble 
consumes the first n PS of the intervals allocated in the UL-MAP. 
That is, UL-MAP entries include the bandwidth for a burst's 
preamble. 


FEC Code Type 


152 


1 


1 = Reed-Solomon only 

2 = Reed-Solomon + Inner (24,16) Block Convolutional Code 
(BCC) 

3 = Reed-Solomon + Inner (9,8) Parity Check Code 

4 = BTC (Optional) 
5-255 = Reserved 


RS information bytes 

TO 


153 


1 


K = 6-255 


RS parity bytes (R) 


154 


1 


R = 0-32 (error correction capability 7=0-16) 


BCC code type 


155 


1 


1 = (24,16) 
2-255 = Reserved 


BTC row code type 


156 


1 


1 = (64,57) Extended Hamming 

2 = (32,26) Extended Hamming 
3-255 = Reserved. 


BTC column code 
type 


157 


1 


1 = (64,57) Extended Hamming 

2 = (32,26) Extended Hamming 
3-255 = Reserved 
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Table 354— UCD burst profile encodings— WirelessMAN-SC 



Name 


T I 

Type 
(1 byte) 


Length 


Value (variable-length) 


BTC interleaving type 


158 


1 


1 = No interleaver, 2 = Block Interleaving, 3-255 = Reserved. 


Randomizer seed 


159 


2 


The 15 bit seed value left-justified in the 2 byte field. Bit 15 is the 
MSB of the first byte, and the LSB of the second byte is not used. 


Last codeword length 


160 


1 


1 = fixed; 2 = shortened 



Table 355— UCD burst profile encodings— WirelessMAN-SCa 



Name 


(1 byte) 


Length 


Value (variable length) 


Modulation type 


150 


1 


4 MSB: 

1 =QPSK, 2 = 16-QAM, 3 = 64-QAM, 4 = 256-QAM, 5 = 
BPSK, 6-10 = Spread BPSK with F s =0-4, 11-15 = Reserved 
4 LSB: 

1 = CC+RS without block interleaving 

2 = CC+RS with block interleaving 

3 = no FEC, 

4 = BTC, 

5 = CTC, 

6-15 = Reserved 


Preamble length 


151 


1 


4 MSB: Number of Unique Words in Preamble (0-7) 
4 LSB: Number of PSs in ramp up (0-15) 


RS Information 
bytes (K) 


152 


1 


tf= 6-239 


RS Parity bytes (R) 


153 


1 


j? = 0-16 bytes (error correction capability = 0-8 bytes) 
R-\n '-255 Reserved 


Block interleaver 
aepm 


154 


1 


Number of rows (Reed-Solomon code words) used in block 
interleaver between Reed-Solomon and CC: 
rows = 2-66; Reserved = 0, 1, 67-255 


CC/CTC-Specific 
parameters 


155 


1 


0 = rate 1/2 (for BPSK, QPSK, 16-QAM) 

1 = rate 2/3 (for QPSK, 64-QAM) 

2 = rate 3/4 (for BPSK, QPSK, 16-QAM, 256-QAM) 

3 = rate 5/6 (for QPSK, 64-QAM) 

4 = rate 7/8 (for QPSK, 256-QAM) 
5-255 = Reserved 


Unique word length 


156 


1 


Number of symbols (U) in a Unique Word: 
0 = 16, 1 = 64, 2 = 256 


Pilot word 
parameters 


157 


1 


4 MSB: Pilot Word Interval 
[Regular bursts] 

(Pilot word's length in symbols included in interval). 

0 = No pilot words, 

1 = 256,2 = 512,3 = 1024, 

4 = 2048, 5 = 4096, 6-15 reserved 
[STC-encoded bursts] 
0 = No pilot words, 

1-15 = Number of paired blocks between pilot words 
4 LSB: Number of contiguous Unique Words composing a Pilot 
Word (1-5) 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS IEEE Std 802.16-2004 



Table 355— UCD burst profile encodings— WirelessMAN-SCa (continued) 



Name 


TVpe 
(1 byte) 


Length 


Value (variable length) 


Burst set type 


158 


1 


0 = Standard, 1 = STC, 2 = Subchannel, 3-255 = Reserved 


STC 

Parameters 


159 


2 


4 MSB: 

oiulk iengin ^segments are paired), in symbols. 
1= 64, 2 = 128, 3 = 256, 4 = 512,..., 7 = 4096, 8-15 Reserved 
4LSB: 

Block burst profile type: 

0 = CP derived from data and no U Ws embedded within block 

1 = CP derived from data an additional UW as first payload 
data element in block 

2 = CP derived from U Ws at beginning and end of segment 
3-15 = Reserved 


BTC Code selector 


160 


1 


Value used to choose set of BTC row/column codes. 
1-3 = C bank 
0, 4-255 = Reserved 


Spreading 
Parameters 


161 


1 


0-15 = PN sequence generator seed labels 0-15, 16-255 = 
Reserved 


Subchannel 
framing parameters 


162 


1 


4 MSB: {k,d} specification 

0= {0,1}, 1 = {0,2} 2= {1,0}, 3= {1,1}, 
4 = {1,2}, 5 = {2,2}, 6-15= Reserved 

4 LSB: Repeat segment length, r, in symbols 
0:7 = 2 A (<value>+8), 7-15= Reserved 



Table 356 — UCD burst profile encodings— WirelessMAN-OFDM 



Name 


Type 
(1 byte) 


Length 


Value (variable length) ; 


FEC Code type 
and modulation 
type 


150 


1 


0 = BPSK (CC) 1/2 11= 64-QAM (BTC) 2/3 

1 = QPSK (RS+CC/CC) 1/2 12 = 64-QAM (BTC) 5/6 

2 = QPSK (RS+CC/CC) 3/4 13 = QPSK (CTC) 1/2 

3 = 16-QAM (RS+CC/CC) 1/2 14 = QPSK (CTC) 2/3 

4 = 16-QAM (RS+CC/CC) 3/4 15 = QPSK (CTC) 3/4 

5 = 64-QAM (RS+CC/CC) 2/3 16 = 16-QAM (CTC) 1/2 

6 = 64-QAM (RS+CC/CC) 3/4 17 = 16-QAM (CTC) 3/4 

7 = QPSK (BTC) 1/2 18 = 64-QAM (CTC) 2/3 

8 = QPSK (BTC) 3/4 19 = 64-QAM (CTC) 3/4 

9 = 1 6-QAM (BTC) 3/5 20-255 = Reserved 
10= 16-QAM (BTC) 4/5 


Focused conten- 
tion power boost 


151 


1 


The power boost in dB of focused contention carriers, as described 
in 8.3.7.3.3. 


TCS_enable 


152 


1 


0 = TCS disabled 

1 = TCS enabled 
2-255 = Reserved 
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UCD burst profile encodings— WirelessMAN-OFDMA 



Name 


(1 byte) 


Length 


Value (variable length) 


FEC Code type 
and modulation 
type 


150 


1 


0 = QPSK (CC) 1/2 

1 = QPSK (CC) 3/4 

2 = 16-QAM (CC) 1/2 

3 = 16-QAM (CC) 3/4 

4 = 64-QAM (CC) 2/3 

5 = 64-QAM (CC) 3/4 

6 = QPSK (BTC) 1/2 

7 = QPSK (BTC) 2/3 

8 = 16-QAM (BTC) 3/5 

9 = 16-QAM (BTC) 4/5 

10 = 64-QAM (BTC) 5/8 
11= 64-QAM (BTC) 4/5 

12 = QPSK (CTC) 1/2 

13 = QPSK (CTC) 2/3 


14 = QPSK (CTC) 3/4 

15 = 16-QAM (CTC) 1/2 

16 = 16-QAM (CTC) 3/4 

17 = 64-QAM (CTC) 2/3 

18 = 64-QAM (CTC) 3/4 

19 = 64-QAM (CTC) 5/6 

20 = QPSK (ZT CC) 1/2 

21 = QPSK (ZTCC) 3/4 
22= 16-QAM (ZT CC) 1/2 
23= 16-QAM (ZT CC) 3/4 
24= 64-QAM (ZT CC) 2/3 
25= 64-QAM (ZT CC) 3/4 
26..255 = Reserved 


Ranging data 
ratio 


151 


1 


Reducing factor in units of 1 dB, between the power used for this burst 
and power should be used for CDMA Ranging. 


Normalized C/N 
override 


152 


5 


This is a list of numbers, where each number is encoded by one nibble, 
and interpreted as a signed integer. The nibbles correspond in order to 
the list define by Table 334, starting from the second line, such that the 
LS nibble of the first byte corresponds to the second line in the table. 
The number encoded by each nibble represents the difference in 
normalized C/N relative to the previous line in the table. 



658 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



11 .4 DCD management message encodings 

The DCD message encodings are specific to the DCD message (see 6.3.2.3.1). 

11.4.1 DCD channel encodings 

The DCD Channel Encoding are provided in Table 358. 



Table 358 — DCD channel encoding 



Name 


TVpe 
(1 byte) 


Length 


Value (variable length) 


PHY 

scope 


Downlink_Burst_ 
Profile 


i 




May appear more than once (see 6.3.2.3.1). The 
length is the number of bytes in the overall object, 

lilllUUllIg C1I1UCUUCU 1 lv iicms. 


All 


BS EIRP 


2 


2 


Signed in units of 1 dBM. 


All | 


Frame duration 


3 


4 


The number of PSs contained in a Burst FDD or TDD 
frame. Required only for framed downlinks. 


SC 


PHY Type 


4 


1 


The PHY Type to be used. 


sc 


Power adjustment 
rule 


5 


1 


0=Preserve Peak Power 
l=Preserve Mean Power 

Describes the power adjustment rule when perform- 
ing a transition from one burst profile to another. 


SC, SCa 


Channel Nr 


6 


1 


Downlink channel number as defined in 8.5. 
Used for license-exempt operation only. 


SCa, 

OFDM, 

OFDMA 


TTG 


7 


1 


TTG (in PSs). 


SCa, 

OFDM, 

UrUMA 


RTG 


8 


. 


RTG (in PSs). 


SCa, 

OFDM, 

OFDMA 




9 


2 


Initial Ranging Max. Received Signal Strength at BS 
Signed in units of 1 dBm. 


All 


Channel Switch 
Frame Number 


10 


3 


Channel switch frame number as defined in 6.3.15.7, 
Used for license-exempt operation only. 


SCa, 

OFDM, 

OFDMA 


Frequency 


12 


4 


Downlink center frequency (kHz). 


All 


BS ID 


13 


6 


Base Station ID. 


SCa, 

OFDM, 

OFDMA 


Frame Duration Code 


14 


1 


The duration of the frame. The frame duration code 
values are specified in Table 232. 


OFDM 


Frame Number 


15 


3 


The number of the frame containing the DCD 
message. 


OFDM 
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Table 358— DCD channel encoding (continued) 



Name 


Type 
(1 byte) 


Length 


Value (variable length) 


PHY 

scope 


Size ofCQICHJD 
field 


16 


1 


0 = Reserved 

1 = 3 bits 

2 = 4 bits 

3 = 5 bits 

4 = 6 bits 

5 = 7 bits 

6 = 8 bits 

7 = 9 bits 

8.. .255 = Reserved 


OFDM A 


H-ARQ ACK delay 
for DL burst 


17 


1 


1 = 1 frame offset 

2 = 2 frame offset 

3 = 3 frame offset 


OFDMA 


MAC version 


148 


1 


See 11.1.3. 


All 



11.4.2 Downlink burst profile encodings 

Downlink burst profile encodings are presented in Table 360. Encodings for TLVs common to all 
specifications are presented in Table 359. 

Table 359— DCD PHY-common burst profile encodings 



Name 


Type 
(1 byte) 


Length 


Value (variable length) 


Frequency 


1 


4 


Downlink frequency (kHz) 



Downlink burst profile encodings that are unique to each PHY specification are provided in Table 360, 
Table 361, Table 362, and Table 363. 



Table 360— DCD burst profile encodings— WirelessMAN-SC 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


Modulation Type 


150 


1 


1 = QPSK 
2=16-QAM 
3 = 64-QAM 


FEC Code Type 


151 


1 


1 = Reed-Solomon only 

2 = Reed-Solomon + Inner Block Convolutional Code j 
(BCC) 

3 = Reed-Solomon + Inner (9,8) Parity Check Code 

4 = BTC (Optional) 
5-255 = Reserved 


RS information bytes (K) 


152 


1 


K =6-255 


RS Parity Bytes (R) 


153 


1 


R = 0-32 (error correction capability T= 0-16) 
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Table 360— DCD burst profile encodings— WirelessMAN-SC (continued) 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


BCC code type 


154 


1 


1 =(24,16) 
2-255 = Reserved 


BTC Row code type 


155 


1 


1 = (64,57) Extended Hamming 

2 = (32,26) Extended Hamming 1 
3-255 = Reserved 


BTC Column code type 


156 


1 


1 = (64,57) Extended Hamming 1 

2 = (32,26) Extended Hamming 
3-255 = Reserved 


BTC Interleaving type 


157 


1 


1 = No interleaver, 2 = Block Interleaving, 
3-255 = Reserved 


Last codeword length 


158 


1 


l=fixed; 2=shortened allowed (optional) 

This allows for the transmitter to shorten the last 
codeword, based upon the allowable shortened 
codewords for the particular code type. 


DIUC mandatory exit threshold 


159 


1. 


CINR at or below which this DIUC can no longer be used 
and at which a change to a more robust DIUC is required, 
in 0.25 dB units. See Figure 81. 


DIUC minimum entry threshold 


160 


1 


The minimum CINR required to start using this DIUC 
when changing from a more robust DIUC is required, in 
0.25 dB units. See Figure 81. 


Preamble presence 


161 ! 


1 


0 = burst not preceded with preamble 

1 = burst preceded with preamble. If the preamble is 

present, it consumes the first PSs of the interval. 


CID_In_DL_IE 


162 


1 


0 - CID does not appear DL-MAP IE (default) 

1 - CID does appear in DL-MAP IE 
2.. 255 - Reserved 



Table 361— DCD burst profile encodings— WirelessMAN-SCa 



Name 


Type 
(1 byte) 


Length 


Value (variable length) 


Modulation type 


150 


1 


4 MSB: 

1 = QPSK, 2 = 16-QAM, 3 = 64-QAM, 4 = 256-QAM, 
5 = BPSK, ,6-9 = Spread BPSK with F s = 0-3, 10-15 = Reserved 
4 LSB: 

1 = CC+RS without block interleaving, 

2 = CC+RS with block interleaving 

3 = no FEC, 4 = BTC, 5 = CTC, 6-15 = Reserved 


RS Information 
bytes (K) 


151 


1 


K-6- 239 


RS Parity bytes (R) 


152 


1 


R = 0-16 bytes (error correction capability = 0-8 bytes) 
/?= 17-255 Reserved 
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Table 361— DCD burst profile encodings— WirelessMAN-SCa (continued) 



Name 


Type 
(1 byte) 


Length 


Value (variable length) 


DIUC Mandatory 
exit threshold 


153 


1 


- 0-63.75 dB 

CINR at or below where this DIUC can no longer be used and at 
which a change to a more robust DIUC is required, in 0.25 dB units. 
See Figure 81. 


DIUC Minimum 
entry threshold 


154 


1 


0-63.75 dB 

The minimum CINR required to start using this DIUC when chang- 
ing from a more robust DIUC is required, in 0.25 dB units. See 
Figure 81. 


CC/CTC-Specific 
parameters 


155 


1 


0 = rate 1/2 (for BPSK, QPSK, 16-QAM) 

1 = rate 2/3 (for QPSK, 64-QAM) 

2 = rate 3/4 (for BPSK, QPSK, 16-QAM, 256-QAM) 

3 = rate 5/6 (for QPSK, 64-QAM) 

4 = rate 7/8 (for QPSK, 256-QAM) 
5-255 = Reserved 


Block interleaver 
Hpnth 


156 


1 


Number of rows (Reed-Solomon code words) used in block inter- 
leaver between Reed-Solomon and CC: 
2-66 = rows 
0, 1, 67-255 = Reserved 


BTC Code selector 


157 


1 


Value used to choose set of BTC row/column codes. 

1-3 = Cbank 

0, 4-255 = Reserved 


Spreading 
Parameters 


159 


1 


0-15 = PN sequence generator seed labels 0-15, 
16-255 = Reserved 


CID_In_DL_IE 


160 


1 


0 = CID does not appear DL-MAP IE (default) 

1 = CID does appear in DL-MAP IE 
2-255 = Reserved 
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Table 362— DCD burst profile encodings— WirelessMAN-OFDM 



Name 


Type 
(1 byte) 


Length 


Value (variable length) 


FEC Code type 


150 


1 


0 = BPSK (CC) 1/2 11= 64-QAM (BTC) 2/3 

1 = QPSK (RS+CC/CC) 1/2 12 = 64-QAM (BTC) 5/6 

3 = 1 6-QAM (RS+CC/CC) 1/2 14 = QPSK (CTC) 2/3 

4 = 16-QAM (RS+CC/CC) 3/4 15 = QPSK (CTC) 3/4 

5 = 64-QAM (RS+CC/CC) 2/3 16 = 16-QAM (CTC) 1/2 

6 = 64-QAM (RS+CC/CC) 3/4 17=1 6-QAM (CTC) 3/4 

7 = QPSK (BTC) 1/2 18 = 64-QAM (CTC) 2/3 

8 = QPSK (BTC) 3/4 or 2/3 19 = 64-QAM (CTC) 3/4 

9 = 1 6-QAM (BTC) 3/5 20-255 = Reserved 
10= 16-QAM (BTC) 4/5 


DIUC mandatory exit 
threshold 


151 


1 


0-63.75 dB 

CINR at or below where this DIUC can no longer be used and 
where this change to a more robust DIUC is required, in 0.25 dB 
units. See Figure 81. 


DIUC minimum entry 
threshold 


152 


1 


0-63.75 dB 

The minimum CINR required to start using this DIUC when 
changing from a more robust DIUC is required, in 0.25 dB units. 
See Figure 81. 


TCS_enable 


153 


1 


0 = TCS disabled 

1 =TCS enabled 
2-255 = Reserved 



Table 363— DCD burst profile encodings— WirelessMAN-OFDM A 



Name 


Type 
(1 byte) 


Length 


Value (variable length) 


FEC Code type 


150 


1 


0 = 


QPSK (CC) 1/2 


14 = 


QPSK (CTC) 3/4 








1 = 


QPSK (CC) 3/4 


15 = 


16-QAM (CTC) 1/2 








2 = 


16-QAM (CC) 1/2 


16 = 


16-QAM (CTC) 3/4 








3 = 


16-QAM (CC) 3/4 


17 = 


64-QAM (CTC) 2/3 








4 = 


64-QAM (CC) 2/3 


18 = 


64-QAM (CTC) 3/4 








5 = 


64-QAM (CC) 3/4 


19 = 


64-QAM (CTC) 5/6 








6 = 


QPSK (BTC) 1/2 


20 = 


QPSK (ZT CC) 1/2 








7 = 


QPSK (BTC) 3/4 or 2/3 


21 = 


QPSK (ZT CC) 3/4 








8 = 


16-QAM (BTC) 3/5 


22= 


16-QAM (ZT CC) 1/2 








9 = 


16-QAM (BTC) 4/5 


23= 


16-QAM (ZT CC) 3/4 








10 


= 64-QAM (BTC) 2/3 or 5/8 


24= 


64-QAM (ZT CC) 2/3 








11 


= 64-QAM (BTC) 5/6 or 4/5 


25= 


64-QAM (ZT CC) 3/4 








12 


= QPSK (CTC) 1/2 


26..255 = Reserved 








13 


= QPSK (CTC) 2/3 






DIUC Mandatory 


151 


1 


0-63.75 dB 






exit 






CINR at or below where this DIUC can no longer be used and 


threshold 






where this change to a more robust DIUC is required, in 0.25 dB 








units. See Figure 81. 






DIUC Minimum 


152 


1 


0-63.75 dB 






entry threshold 






The minimum CINR required to 


start 


using this DIUC when chang- 








ing 


from a more robust DIUC is 


required, in 0.25 dB units. See 








Figure 81. 
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11.5 RNG-REQ management message encodings 

The encodings in Table 364 are specific to the RNG-REQ message (6.3.2.3.5). 



Table 364— RNG-REQ message encodings 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


PHY 

Scope 


Requested Downlink 
Burst Profile 


1 


1 


tiitc n_l« r^TTir 1 r»f thp Hnwnlink hurst nrofile 
requested by the SS for downlink traffic. 
Bits 4-7: 4 LSB of Configuration Change Count 
value of DCD defining the burst profile associated 
with DIUC. 


All 


SS MAC Address 


2 


6 


The MAC address of the SS 


All 


Ranging Anomalies 


3 


1 


A parameter indicating a potential error condition 
detected by the SS during the ranging process. Setting 
the bit associated with a specific condition indicates 
that the condition exists at the SS. 

Bit #0 — SS already at maximum power. 

Bit #1 — SS already at minimum power. 

Bit #2 — Sum of commanded timing adjustments is 

too large. 


All 


AAS broadcast 
capability 


4 


1 


0 = SS can receive broadcast messages 

1 = SS cannot receive broadcast messages 


SCa, 

OFDM, 

OFDMA 



Table 365— SCa-specif ic RNG-REQ message encodings 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


SCa AAS feedback 


150 


6 


Bytes #0-1 : Phase offsets 
Bits #0-4: Antenna 1 relative to antenna 0 

signed value units of 360°/32 
Bits #5-9: Antenna 2 relative to antenna 0 

signed value units of 360°/32 
Bits #10-14: Antenna 3 relative to antenna 0 

signed value units of 360°/32 
Bit #15: Reserved; shall be set to zero 

Antenna CINR values (see 8.2.2) 
Byte #2 - Antenna 0 
Byte #3 - Antenna 1 
Byte #4 - Antenna 2 
1 Byte #5 - Antenna 3 
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11.6 RNG-RSP management message encodings 

The encodings in Table 367 are specific to the RNG-RSP message (6.3.2.3.6). 



Table 366— SCa-specific RNG-RSP message encodings 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


A AS preamble index 


150 


1 


0, 1, 2, 3 = Index of the AAS preamble to be used on 
future AAS transmissions to the SS 



Table 367— RNG-RSP message encodings 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


PHY 

Scope 


Timing Adjust 


1 


4 


Tx timing offset adjustment (signed 32-bit). The time 
required to advance SS transmission so frames arrive 
at the expected time instance at the BS. Units are PHY 
specific (see 10.3). 


All 


Powpr I .pvpI AHinst 

A. \J VY \sl IjVVLI nujudi 


2 


I 


Tx Pnwpr nffcpt nHiimtmpnt fcionpH R-hit ft ?S HR 

units) 

Specifies the relative change in transmission power 
level that the SS is to make in order that transmissions 
arrive at the BS at the desired power. When subchan- 
nelization is employed, the subscriber shall interpret 
the power offset adjustment as a required change to 
the transmitted power density. 


All 

/All 


Offset Frequency Adjust 


3 


4 


Tx frequency offset adjustment (signed 32-bit, Hz 
units) 

Specifies the relative change in transmission 
frequency that the SS is to make in order to better 
match the BS. (This is fine-frequency adjustment 
within a channel, not reassignment to a different chan- 
nel.) 


All 


Ranging Status 


4 


1 


Used to indicate whether uplink messages are received 
within acceptable limits by BS. 

1 = continue, 2 = abort, 3 = success, 4 = rerange 


All 


Downlink frequency 
override 


5 


4 


Center frequency, in kHz, of new downlink 
channel where the SS should redo initial ranging. 

If this TLV is used, the Ranging Status value shall be 
set to 2. Shall be used for licensed bands only. 


SCa 

OFDM 

OFDMA 


Uplink channel ID override 


6 


1 


Licensed bands: The identifier of the uplink 
channel with which the SS is to redo initial 
ranging (not used with PHYs without channelized 
uplinks). 

License-exempt bands: The Channel Nr (see 8.5.1) 
where the SS should redo initial ranging. 


All 
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Table 367 — RNG-RSP message encodings (continued) 



Name 


Type 
(1 byte) 


Length 


Value 

/ 1iar { n Kid 1 ATI 41 1 Vl I 

{variauie-icnguij 


PHY 

Scope 


Downlink Operational 
Burst Profile 


7 


2 


This parameter is sent in response to the RNu-Kbg 
Requested Downlink Burst Profile parameter. 
Byte 0: Specifies the least robust DIUC that may be 
used by the BS for transmissions to the SS. 
Byte 1 : Configuration Change Count value of DCD 
defining the burst profile associated with DIUC. 


All 

All 


SS MAC Address 


8 


6 


SS MAC Address in MAC-48 format 


All 


Basic CID 


9 


2 


Basic CID assigned by BS at initial access. 


All 


Primary Management CID 


10 


2 


Primary Management CID assigned by BS at initial 
access. 


All 


AAS broadcast 
permission 


11 


1 


0 = SS may issue contention-based Bandwidth 
Requests permission 

1 = SS shall not issue contention-based Bandwidth 
Request 


oCa 

OFDM 

OFDMA 


Frame number 


lz 


j 


F?ri»mp number where the associated RNG REO mes- 
sage was detected by the BS. Usage is mutually exclu- 
sive with SS MAC Address (Type 8). The opportunity 
within the frame is assumed to be 1 (the first) if the 
Initial Ranging Opportunity field is not supplied. 


SCa 
OFDM 


Initial ranging 
opportunity number 


13 


1 


Initial Ranging opportunity (1-255) in which the asso- 
ciated RNG_REQ message was detected by the BS. 
Usage is mutually exclusive with SS MAC Address 
| (Type 8). 


SCa 
OFDM 



In addition to the RNG-RSP TLVs listed in Table 367, which are applicable to multiple PHY specifications, 
sets of PHY specification specific RNG-RSP TLVs are provided in Table 368 and Table 369. 



Table 368— OFDM-specific RNG-RSP message encodings 



Name 


Type 


Length 


Value 


Ranging subchannel 


150 


1 


Used to indicate the OFDM subchannel reference that was 
used to transmit the initial ranging message (OFDM with 
subchannelization). Ranging subchannels are numbered 
from 01 to OxlF according to Table 213. : 



Table 369— OFDMA-specific RNG-RSP message encodings 



Name 1 Type 


Length 


Value 


Ranging code attributes 


150 


4 


Bits 31:22- Used to indicate the OFDM time symbol reference 
that was used to transmit the ranging code. 

Bits 21:16- Used to indicate the OFDMA subchannel reference 
that was used to transmit the ranging code. 

Bits 15:8 - Used to indicate the ranging code index that was 
sent by the SS. 

Bits 7:0 - The 8 least significant bits of the frame number of the 
OFDMA frame where the SS sent the ranging code. 
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11.7 REG-REQ/RSP management message encodings 

The TLV encodings defined in this subclause are specific to the REG-REQ (6.3.2.3.7), and REG-RSP 
(6.3.2.3.8) MAC Management messages. 

11.7.1 ARQ Parameters 

This field provides the fragmentation and ARQ parameters applied during the establishment of the 
secondary management connection. For purposes of ARQ parameter negotiation, the appearance of the field 
in the REG-REQ message is equivalent to its appearance in the DS A-REQ message. The appearance of the 
field in the REG-RSP message is equivalent to its appearance in the DSA-RSP message. 

This field is a compound TLV that may take on any of the ARQ parameters described in 11.13.18. The 
subtype values defined for use within the 145/146 service flow definitions are applicable for this TLV as 
well. 



Type 


Length 


Value 


Scope 


1 


variable 


Compound 


REG-REQ 
REG-RSP 



11.7.2 SS management support 

This field indicates whether or not the SS is managed by standard- based IP messages over the secondary 
management connection. When the SS indicates in the REG-REQ that it is managed, the BS and SS shall 
perform stages g), h), and i) of the initial network entry process (see 6.3.9). Otherwise, these stages shall be 
skipped by the BS and SS. 



Type 


Length 


Value 


Scope 


2 


1 


0: no secondary management connection 
1 : secondary management connection 


REG-REQ 
REG-RSP 



11.7.3 IP management mode 

The IP management mode parameter dictates whether the provider intends to manage the SS on an ongoing 
basis via IP-based mechanisms. 



Type 


Length 


Value 


Scope 


3 


1 


0 - Unmanaged mode 

1 - IP-managed mode 


REG-REQ (see 6.3.2.3.7), 
REG-RSP (see 6.3.2.3.8) 
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11.7.4 IP version 

This field indicates the version of IP used on the Secondary Management Connection. 



Type 


Length 


Value 


Scope 


4 


1 


Bits #0: 4 (default) 
Bits #1:6 

Bits #2-7: Reserved; shall be set to zero 


REG-REQ 
REG-RSP 



11.7.5 Secondary Management CID 

This parameter contains the Secondary Management CID issued to an SS . 



Type 


Length 


Value 


Scope 


5 


2 


Secondary Management CID 


REG- RSP 



11.7.6 Number of uplink CID supported 

This field shows the number of Uplink CIDs the SS can support. The minimum value is three for managed 
SSs and two for unmanaged SSs. An SS shall support a Basic CID, a Primary Management CID, and 0 or 
more Transport CIDs. A managed SS shall also support a Secondary Management CID. 



Type 


Length 


Value 


Scope 


6 


2 


Number of Uplink CIDs the SS can support. 


REG-REQ, REG-RSP 



11.7.7 Convergence Sublayer Capabilities 

11.7.7.1 Classification/PHS options and SDU encapsulation support 

This parameter indicates which classification/PHS options and SDU encapsulation the SS supports. By 
default, Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence of this parameter in REG-REQ 
means that named options are supported by the SS. 



Type 


Length 


Value 


Scope 


7 


2 


Bit #0: ATM 

Bit #1: Packet, IPv4 

Bit #2: Packet, IPv6 

Bit #3: Packet, 802.3/Ethernet 

Bit #4: Packet, 802. 1Q VLAN 

Bit #5: Packet, IPv4 over 802.3/Ethernet 

Bit #6: Packet, IPv6 over 802.3/Ethernet 

Bit #7: Packet, IPv4 over 802. 1Q VLAN 

Bit #8: Packet, IPv6 over 802.1Q VLAN 

Bits #9-15: Reserved; Shall be set to zero 


REG-REQ 
REG-RSP 
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11.7.7.2 Maximum number of classifiers 

This is the maximum number of admitted Classifiers that the SS supports. 



Type 


Length 


Value 


Scope 


8 


2 


Maximum number of simultaneous 
admitted classifiers 


REG-REQ 
REG-RSP 



The default value is 0 (no limit). 
11.7.7.3 PHS support 

This parameter indicates the level of PHS support. 



Type 


Length 


Value 


Scope 


9 


2 


0: no PHS support 


REG-REQ 






1: ATM PHS 


REG-RSP 






2: Packet PHS 





The default value is 0 (no PHS). 
11.7.8 SS capabilities encodings 
11.7.8.1 ARQ Support 

This field indicates the availability of SS support for ARQ. 



Type 


Length 


Value 


Scope 


10 


1 


0: No ARQ support capability 
1 : ARQ supported 
2-255: Reserved 


REG-REQ 
REG-RSP 



11.7.8.2 DSx flow control 

This field specifies the maximum number of concurrent DSA, DSC, or DSD transactions that may be 
outstanding. 



Type 


Length 


Value 


Scope 


11 


1 


0 indicates no limit (default) 

1-255 indicate maximum concurrent transactions 


REG-REQ 
REG-RSP 
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11 .7.8.3 MAC CRC support 

This field indicates whether or not the SS supports MAC level CRC. A value of 0 indicates no CRC support. \ 
A value of 1 indicates that the SS supports MAC CRC. 



Type 


Length 


Value 


Scope 


i 12 


1 


0 = No MAC CRC support 

1 = MAC CRC support (default) 


REG-REQ 
REG-RSP 



1 1 .7.8.4 MCA flow control 

This field specifies the maximum number of concurrent MCA transactions that may be outstanding. 



Type 


Length 


Value 


Scope 


13 


1 


0 indicates no limit (default) 

1-255 indicate maximum concurrent transactions 


REG-REQ 
REG-RSP 



11.7.8.5 Multicast polling group CID support 

This field indicates the maximum number of simultaneous Multicast Polling Groups the SS is capable of 
belonging to. 



Type 


Length 


Value 


Scope 


14 


1 


0-255 
default =0 


REG-REQ 
REG-RSP 



11.7.8.6 PKM flow control 

This field specifies the maximum number of concurrent PKM transactions that may be outstanding. 



Type 


Length 


Value 


Scope 


15 


1 


0 indicates no limit (default) 

1-255 indicate maximum concurrent transactions 


REG-REQ 
REG-RSP 



11.7.8.7 Authorization Policy Support 

This field indicates authorization policy that both SS and BS need to negotiate and synchronize. A bit value 
of 0 indicates "not supported" while 1 indicates "supported." If this field is omitted, then both SS and BS 
shall use the IEEE 802.16 security, constituting X.509 digital certificates and the RSA public key encryption 
algorithm, as authorization policy. 



Type 


Length 


Value 


Scope 


16 


1 


Bit #0: IEEE 802.16 privacy supported 
Bits #1-7: Reserved; shall be set to zero 


REG-REQ 
REG-RSP 
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11.7.8.8 Maximum number of supported security associations 

This field specifies the maximum number of supported security association of the SS. 





Length 


Value 


Scope 


17 


1 


Maximum number of security association 
supported by the SS (default = 1) 


REG-REQ 
REG-RSP 



11.8 SBC-REQ/RSP management message encodings 

The TLV encodings defined in this subclause are specific to the SBC-REQ (6.3.23.23), and SBC-RSP 
(6.3.2.3.24) MAC Management message dialog. 

11.8.1 Bandwidth Allocation Support 



This field indicates properties of the SS that the BS needs to know for bandwidth allocation purposes. 



Type 


Length 


Value 


Scope 


1 


1 


Bit #0: Reserved; shall be set to zero 
Bit #1 = 0: Half-Duplex (FDD only) 
Bit #1 = 1: Full-Duplex (FDD only) 
Bits #2-7: Reserved; shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 


11.8.2 Capabilities for Construction and Transmission of MAC PDUs 


Type 


Length 


Value 


Scope 


4 


1 


Bit #0: Ability to receive requests piggybacked with data 
Bit #1 : Specifies the size of FSN values used when forming 
MAC PDUs on non-ARQ connections 
0: Only 3-bit FSN values are supported 
1: Only 11 -bit FSN values are supported 
Bits #2-7: Reserved; shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3 Physical Parameters Supported 



11.8.3.1 Subscriber transition gaps 

This field indicates the transition speed SSTTG and SSRTG for TDD and H-FDD SSs. This parameter is not 
used by WirelessMAN-SC. Instead, performance is mandated in Table 169. 



Type 


Length 


Value 


Scope 


2 


2 


Bits #0-7:' SSTTG (|xs) 
Bits #8-15: SSRTG ([is) 
Allowed values: 

OFDM mode: TDD and H-FDD 0...100. 
Other modes: TDD: 0...50; H-FDD: 0...100 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.2 Maximum transmit power 

The maximum available power for BPSK, QPSK, 16-QAM, and 64-QAM constellations. The maximum 
power parameters are reported in dBm and quantized in 0.5 dBm steps ranging from -64 dBm (encoded 
0x00) to 63.5 dBm (encoded OxFF). Values outside this range shall be assigned the closest extreme. SSs that 
do not support QAM64 shall report the value of 0x00 in the maximum QAM64 power field. This parameter 
is only applicable to systems supporting the SCa, OFDM or OFDMA PHY specifications. 



Type 


Length 


Value 


Scope 


3 


4 


Byte 0: Maximum transmitted power for BPSK. 
Byte 1: Maximum transmitted power for QPSK. 
Byte 2: Maximum transmitted power for 16-QAM. 
Byte 3: Maximum transmitted power for 64-QAM. SSs 

that do not support 64-QAM shall report the 

value 0x00. 


SBC-REQ 



1 1 .8.3.3 Current transmit power 

This parameter indicates the transmitted power used for the burst which carried the message. The parameter 
is defined in the common TLV encodings subclause (11.1.1). When included in an SBC-REQ message, the 
TLV is encapsulated in the physical supported parameters compound TLV. 



Type 


Length 


Value 


Scope 


147 


1 


Current transmitted power (11.1.1) 


SBC-REQ 



11.8.3.4 WirelessMAN-SC specific parameters 
11.8.3.4.1 SC SS demodulator types 

This field indicates the different modulation types supported by an SS for downlink reception. This field is 
not used for other PHY specifications. A bit value of 0 indicates "not supported" while 1 indicates 
"supported." 



Type 


Length 


Value 


Scope 


150 


1 


Bit#0: QPSK 
Bit #1: 16-QAM 
Bit #2: 64-QAM 

Bits #3-7: Reserved; shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.4.2 SC SS modulator types 

This field indicates the different modulation types supported by an SS for uplink transmission. This field is 
not used for other PHY specifications. A bit value of 0 indicates "not supported" while 1 indicates 
"supported." 



Type 


Length 


Value 


Scope 


151 


1 


Bit #0: QPSK 
Bit #1: 16-QAM 
Bit #2:64-QAM 

Bits #3-7: Reserved, shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.4.3 SC SS downlink FEC types 

This field indicates the different FEC types supported by an SS for downlink reception. This field is not used 
for other PHY specifications. A bit value of 0 indicates "not supported" while 1 indicates "supported." 



TVpe 


Length 


Value 


Scope 


152 


1 


Bit #0: Code Type 1 as in Table 146 
Bit #1: Code Type 2 as in Table 146 
Bit #2: Code TVpe 3 as in Table 123 
Bits #3-7: Reserved, shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.4.4 SC SS uplink FEC types 

This field indicates the different FEC types supported by an SS for uplink transmission. This field is not 
used for other PHY specifications. A bit value of 0 indicates "not supported," while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


153 


1 


Bit #0: Code Type 1 as in Table 146 
Bit #1 : Code Type 2 as in Table 146 
Bit #2: Code Type 3 as in Table 123 
Bits #3-7: Reserved, shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.5 WirelessMAN-SCa specific parameters 
11 .8.3.5.1 SCa SS demodulation types 

This field indicates the optional modulation (and FEC) types supported by an SS for downlink reception. 
Note that BPSK, QPSK, 16-QAM, and 64-QAM shall be supported, as is the Concatenated FEC and no- 
FEC QPSK. A bit value of 0 indicates "not supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


150 


1 


Bit #0: 256-QAM 
Bit #1 : BTC 
Bit#2:CTC 

Bit #3: no FEC and QAM 
Bit #4: STC support, dual blocks without 
UWs 

Bit #5: STC support, dual blocks with UWs 
Bits #6-7: Reserved', shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.2 SCa SS demodulator roll-off factor 

This field indicates the optional roll-off factors supported by an SS for downlink reception. Note that support 
of a roll-factor of 0.25 is mandatory. A bit value of 0 indicates "not supported" while 1 indicates 
"supported." 



Type 


Length 


Value 


Scope 


151 


1 


Bit #0: 0.15 
Bit #1:0.18 

Bits #2-7: Reserved', shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.3 SCa SS demodulator Unique Word length 

This field indicates the optional Unique Word lengths, in symbols, supported by an SS for downlink 
reception. Note that support of the 64-symbol Unique Word is mandatory. A bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


152 


1 


Bit #0: 256 

Bits #1-7: Reserved', shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.5.4 SCa SS demodulator block interleaver depth 

This field indicates the interleaver depth (number of rows) supported by an SS for downlink reception. The 
value of 0 (interleaver depth 10 rows) shall be supported. 



Type 


Length 


Value 


Scope 


153 


1 


0: interleaver depth of 10 rows 
1-54: 11-64 rows 
55-255: Reserved 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.5 SCa SS demodulator STC block size 

This field indicates the STC block size (block = 1/2 length of a "STC pair") supported by an SS for down- 
link reception. A bit value of 0 indicates "not supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


155 


1 


Bit#0: 64 
Bit #1:128 
Bit #2:256 
Bit #3:512 
Bit #4: 1024 
Bit #5:2048 
Bit #6: 4096 

Bit #7: Reserved, shall be set to 0. 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.6 SCa SS modulation types 

This field indicates the optional modulation (and FEC) types supported by an SS for uplink transmission. 
Note that QPSK, 16-QAM, and 64-QAM shall be supported, as is the Concatenated FEC without block 
interleaving and no-FEC QPSK. A bit value of 0 indicates "not supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


156 


1 


Bit #0: 256-QAM 
Bit #1: BTC 
Bit #2: CTC 

Bit #3: no FEC and QAM 
Bit #4: STC support, dual blocks without 
UWs 

Bit #5: STC support, dual blocks with UWs 
Bits #6,7: Reserved, shall be set to 0. 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.5.7 SCa SS modulator roll-off factor 

This field indicates the optional roll-off factors supported by an SS for uplink transmission. Note that 
support of a roll-factor of 0.25 is mandatory. A bit value of 0 indicates "not supported" while 1 indicates 
"supported." 



Type 


Length 


Value 


Scope 


157 


1 


Bit #0:0.15 
Bit #1:0.18 

Bits #2-7: Reserved; shall be set to 0. 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.8 SCa SS modulator unique word length 

This field indicates the optional Unique Word lengths, in symbols, supported by an SS for uplink 
transmission. Note that support of the 64-symbol Unique Word is mandatory. A bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



TVpe 


Length 


Value 


Scope 


158 


1 


Bit #0: 256 

Bits #1-7: Reserved; shall be set to 0. 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.9 SCa SS modulator block interleaver depth 

This field indicates the interleaver depth (number of rows) supported by an SS for uplink transmission. The 
value of 0 (interleaver depth 10 rows) shall be supported. 



Type 


Length 


Value 


Scope 


159 


1 


0: interleaver depth of 10 rows 
1-54: 11-64 rows 
55-255: Reserved 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.10 SCa SS modulator STC block size 

This field indicates the STC block size (block = 1/2 length of a "STC pair") supported by an SS for uplink 
transmission. A bit value of 0 indicates "not supported" while 1 indicates "supported." 
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Type 


Length 


Value 


Scope 


161 


1 


Bit #0: 64 
Bit #1: 128 
Bit #2: 256 
Bit #3:512 
Bit #4: 1024 
Bit #5:2048 
Bit #6: 4096 

Bit #7: Reserved y shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.11 SCa SS modulator maximum uplink channel width 

This field indicates the maximum uplink channel width over which an SS can transmit. 





Length 


Value 


Scope 


162 


2 


Bits #0-15: Channel Width, in 10 kHz increments. 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.12 SCa SS modulator minimum uplink channel width 

This field indicates the minimum uplink channel width over which an SS can transmit. 



Type 


Length 


Value 


Scope 


163 


2 


Bits #0-15: Channel Width, in 10 kHz 
increments. 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.5.13 SCa SS modulator power control limits 

This field indicates the maximum transmit power, power control range, and power control granularity that an 
SS can deliver to the transmit antenna over the given uplink channel. 



Type 


Length 


Value 


Scope 


164 


3 


Bits #0-5: Maximum output power in dBm, from 0 to 63 
Bits #6-12: Power control range, in dB, from 0 to 127 
Bits #13-17: Power control granularity in 0.25 dB 

increments, from 0.25 to 8 dB. 
Bits #18-23: Reserved; shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.5.14 SCa SS modulator Subchannel framing support 

This field indicates the lengths of a Repeat Segment in a subchannel burst set supported by an SS for uplink 
transmission. A bit value of 0 indicates "not supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


165 


1 


Bit #0: r = 256 
Bit#l:r=512 
Bit#2:r= 1024 
Bit #3:r = 2048 
Bit #4: r = 4096 
Bit #5: r= 8096 

Bits #6-7: Reserved; shall be set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11 .8.3.5.15 SCa maximum transmit power 

This parameter indicates the maximum available power for BPSK, QPSK, 16-QAM, 64-QAM, and 256-QAM 
constellations. The maximum power parameters are reported in dBm and quantized in 0.5 dBm steps ranging 
from -64 dBm (encoded 0x00) to 63.5 dBm (encoded OxFF). Values outside this range shall be assigned the 
closest extreme. SSs that do not support 256-QAM shall report the value of 0x00 in the maximum 256-QAM 
power field. 



Type 


Length 


Value 


Scope 


166 


5 


Byte 0: Transmit power backoff for BPSK 
Byte 1: Transmit power backoff for QPSK 
Byte 2: Transmit power backoff for 
16-QAM 

Byte 3: Transmit power backoff for 

64-QAM 
Byte 4: Transmit power backoff for 

256-QAM. SSs that do not support 

256-QAM shall report the value 

0x00. 


SBC-REQ (see 6.3.2.3.23) 



11 .8.3.6 WirelessMAN-OFDM specific parameters 
11.8.3.6.1 OFDM SS FFT sizes 

This field indicates the FFT sizes supported by the SS. For each FFT size, a bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


150 


1 


Bit #0: FFT-256 
Bit#l:FFT-2048 

Bits #2-7: Reserved, shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.6.2 OFDM SS demodulator 

This field indicates the different demodulator options supported by a WirelessMAN-OFDM PHY SS for 
downlink reception. This field is not used for other PHY specifications. A bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


151 


1 


Bit #0: 64-QAM 
Bit #1: BTC 
Bit #2: CTC 
Bit#3:STC 
Bit #4: AAS 

Bits #5-7: Reserved', shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.6.3 OFDM SS modulator 

This field indicates the different modulator options supported by a WirelessMAN-OFDM PHY SS for 
uplink transmission This field is not used for other PHY specifications. A bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


152 


1 


Bit#0: 64-QAM 
Bit# 1 : BTC 
Bit# 2: CTC 

Bit# 3: Subchannelization 

Bit# 4: Focused contention BW request 

Bits# 5-7: reserved. Set to 0 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.6.4 OFDM SS focused contention support 

This field indicates whether the SS supports Focused Contention (see 8.3.7.3.3). A bit value of 0 indicates 
"not supported" while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


153 


1 


Bit #0: Focused Contention Support 
Bits #1-7: Reserved, shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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1 1 .8.3.6.5 OFDM SS TC sublayer support 

This field indicates whether or not the SS supports the TC sublayer (see 8.3.4). A bit value of 0 indicates 
"not supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


154 


1 


Bit #0: TC sublayer support; default value = 0 
Bits #1-7: Reserved, shall be set to zero 


SBC-REQ (see 63.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.7 WirelessMAN-OFDMA specific parameters 
11.8.3.7.1 OFDM A SS FFT sizes 

This field indicates the FFT sizes supported by the SS. For each FFT size, a bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


150 


1 


Bit #0: FFT-256 
Bit#l:FFT-2048 

Bits #2-7: Reserved, shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.7.2 OFDM A SS demodulator 

This field indicates the different demodulator options supported by a WirelessMAN-OFDMA PHY SS for 
downlink reception. This field is not used for other PHY specifications. A bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


151 


1 


Bit #0: 64-QAM 
Bit #1:BTC 
Bit #2: CTC 
Bit #3: STC 

Bit #4: AAS Diversity Map Scan 
Bit #5: AAS Direct Signaling 
Bit #6: H-ARQ 

Bit #7: Reserved; shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 
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11.8.3.7.3 OFDM A SS modulator 

This field indicates the different modulator options supported by a WirelessMAN-OFDMA PHY SS for 
uplink transmission This field is not used for other PHY specifications. A bit value of 0 indicates "not 
supported" while 1 indicates "supported." 



Type 


Length 


Value 


Scope 


152 


1 


Bit# 0: 64-QAM 
Bit# 1: BTC 
Bit# 2: CTC 

Bit# 3: AAS Diversity Map Scan 
Bit#4: AAS Direct Signaling 
Bit# 5: H-ARQ 

Bits# 6-7: Reserved', shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 


153 


1 


The number of H ARQ ACK Channel 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.8.3.7.5 OFDM A SS Permutation support 

This field indicates the different optional OFDMA permutation modes (optional PUSC, optional FUSC and 
AMC) supported by a WirelessMAN-OFDMA SS. A bit value of 0 indicates "not supported" while 1 
indicates "supported." 



Type 


Length 


Value 


Scope 


154 


1 


Bit# 0: Optional PUSC support 
Bit# 1: Optional FUSC support 
Bit# 2: AMC support 
Bits# 3-7: Reserved, shall be set to zero 


SBC-REQ (see 6.3.2.3.23) 
SBC-RSP (see 6.3.2.3.24) 



11.9 PKM-REQ/RSP management message encodings 

A summary of the TLV encoding format is shown below. The fields are transmitted from left to right. 





Length 


Value 


1 byte 


variable 


Length bytes 



Type: The Type field is one byte. Values of the PKM Type field are specified in Table 370. Note that Type 
values between 0 and 127 are defined within the PKM Specification, while values between 128 and 255 are 
vendor-assigned Attribute Types. 

— A PKM server shall ignore attributes with an unknown type. 

— A PKM client shall ignore attributes with an unknown type. 

— PKM client and server (i.e., SS and BS) may log receipt of unknown attribute types. 
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Length: The Length field indicates the length of this attribute's Value field, in bytes. The length field does 
not include the Type and Length fields. 

Value: The Value field is zero or more bytes and contains information specific to the attribute. The format 
and length of the Value field is determined by the Type and Length fields. 

— The format of the value field is one of the five data types shown in Table 371. 



Table 370 — PKM attribute types 



Type 


PKM attribute 


0-5 


reserved 


6 


Display-String 


7 


AUTH-Key 


8 


TEK 


9 


Key-Lifetime 


10 


Key-Sequence-Number 


11 


HMAC-Digest 


12 


SAID 


13 


TEK-Parameters 


14 


reserved 


15 


CBC-IV 


16 


Error-Code 


17 


CA-Certificate 


18 


SS-Certificate 


19 


Security-Capabilities 


20 


Cryptographic-Suite 


21 


Cryptographic-Suite-List 


22 


Version 


23 


SA-Descriptor i 


24 


SA-Type 


25 


reserved 


26 


reserved 


27 


PKM Configuration Settings 


28-255 


reserved 
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Data type 


Structure 


string 


0 - n bytes 


uint8 


8-bit unsigned integer 


uintl6 


16-bit unsigned integer 


uint32 


32-bit unsigned integer 


compound 


collection of attributes 



11.9.1 Display string 

Description: This attribute contains a textual message. It is typically used to explain a failure response and 
might be logged by the receiver for later retrieval by an SNMP manager. Display strings shall be no longer 
than 128 bytes. A summary of the Display-String attribute format is shown below. The fields are transmitted 
from left to right. 



Type 


Length 


Value (string) 


6 


> 0 and < 128 


A string of characters. The character string shall be null-terminated. 



11.9.2 AUTH-Key 

Description: The AK (AUTH-Key) is a 20 byte quantity, from which a KEK, and two message 
authentication keys (one for uplink requests, and a second for downlink replies) are derived. This attribute 
contains a 128 byte quantity containing the AK RSA-encrypted with the SS's 1024 bit RSA public key. 
Details of the RSA encryption procedure are given in 7.5. The ciphertext produced by the RSA algorithm 
shall be the length of the RSA modulus, i.e., 128 bytes. 



Type 


Length 


Value (string) 


7 


128 


128 byte quantity representing an RSA-encrypted AK. 



11.9.3 TEK 

Description: This attribute contains a quantity that is a TEK key, encrypted with a KEK derived from the 
AK. 



Type 


Length 


Value (string) 


8 


8 


Encrypted TEK. 
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11.9.4 Key lifetime 

Description: This attribute contains the lifetime, in seconds, of an AK or a TEK. It is a 32-bit 
quantity representing the number of remaining seconds for which the associated key shall be valid, 
this attribute can be used as top level attribute (AK) as well as a subattribute (TEK). 



Type 


Length 


Value (uint32) 


9 


4 


32-bit quantity representing key lifetime 

A key lifetime of zero indicates that the corresponding AK or TEK is not 
valid. 



11.9.5 Key-Sequence-Number 

Description- This attribute contains sequence number for a TEK or AK. The 2-bit or 4-bit quantity, however, 
is stored in a single byte, with the high-order 6 or 4 bits set to 0. A summary of the Key- Sequence-Number 
attribute format is shown below. Note that this attribute can be used as top level attribute (AK) as well as a 
subattribute (TEK). 



Type 


Length 


Value (uint8) 


10 


1 


2-bit sequence number (TEK) 
4-bit sequence number (AK) 



11.9.6 HMAC-Digest 

Description: This attribute contains a keyed hash used for message authentication. The HM AC algorithm i 
defined in IETF RFC 2 104. 



Type 


Length 


Value (string) 


11 


20 bytes 


A 160-bit (20 byte) keyed SHA hash 



11.9.7 SAID 

Description: This attribute contains a 16-bit SAID used by the Privacy Protocol to identify 



Type 


Length 


Value (uintl6) 


12 


2 


16-bit quantity representing an SAID 
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11.9.8 TEK parameters 

Description: This attribute is a compound attribute, consisting of a collection of subattributes. These 
subattributes represent all security parameters relevant to a particular generation of an SAID's TEK. A 
summary of the TEK-Parameters attribute format is shown below. 



Type 


Length 


Value (compound) 


13 


variable 


The Compound field contains the subattributes as 
defined in Table 372 



Table 372— TEK-parameters subattributes 



Attribute 


Contents 


TEK 


TEK, encrypted with the KEK 


Key-Lifetime 


TEK Remaining Lifetime 


Key-Sequence-Number 


TEK Sequence Number 


CBC-IV 


CBC Initialization Vector 



11.9.9 CBC-IV 

Description: This attribute contains a value specifying a CBC Initialization Vector (CBC-IV). A summary of 
the CBC-IV attribute format is shown below. The fields are transmitted from left to right. 



Type 


Length 


Value (string) 


15 


Equal to Block length of cipher 


CBC-IV 



11.9.10 Error code 

Description: This attribute contains a 1-byte error code providing further information about an' 1 
Authorization Reject, Key Reject, Authorization Invalid, or TEK Invalid. A summary of the Error-Code 
attribute format is shown below. Table 373 lists code values for use with this attribute. The BS may employ 
the nonzero error codes (1-6) listed below; it may, however, return a code value of zero (0). Error code 
values other than those defined in Table 373 shall be ignored. Returning a code value of zero sends no 
additional failure information to the SS; for security reasons, this may be desirable. 



Type 


Length 


Value (uint8) 


Scope 


16 


1 


Error-Code 


Authorization Reject, 
Authorization Invalid, Key 
Reject, TEK Invalid 
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Table 373— Error-code attribute code values 



Error Code 


Messages 


Description 


0 


All 


No information 


1 


Auth Reject, Auth Invalid 


Unauthorized SS 


2 


Auth Reject, Key Reject 


Unauthorized SAID 


3 


Auth Invalid 


Unsolicited 


4 


Auth Invalid, TEK Invalid 


Invalid Key Sequence Number 


5 


Auth Invalid 


Message (Key Request) authentication failure 


6 


Auth Reject 


Permanent Authorization Failure 



Error Code 6 (Permanent Authorization Failure) is used to indicate a number of different error conditions 
affecting the PKM authorization exchange. These include: 

a) An unknown manufacturer; i.e., the BS does not have the CA certificate belonging to the issuer of an 
SS certificate 

b) SS certificate has an invalid signature 

c) ASN. 1 parsing failure during verification of S S certificate 

d) SS certificate is on the "hot list" 

e) Inconsistencies between certificate data and data in accompanying PKM attributes 

f) SS and BS have incompatible security capabilities 

The common property of these error conditions is that the failure condition is considered permanent; 
any reattempts at authorization would continue to result in Authorization Rejects. Details about the 
cause of a Permanent Authorization Failure may be reported to the SS in an optional Display-String 
attribute that may accompany the Error-Code attribute in Authorization Reject messages. Note that 
providing this additional detail to the SS should be administratively controlled within the BS. The 
BS may log these Authorization failures, or even trap them to an SNMP manager. 

11.9.11 CA certificate 

Description: This attribute is a string attribute containing an X.509 CA Certificate, as defined in 7.6. A 
summary of the CA-Certificate attribute format is shown below. The fields are transmitted from left to right. 



Type 


Length 


Value (string) 


17 


Variable. 

Length shall not cause resulting MAC management 
message to exceed the maximum allowed size. 


X.509 CA Certificate (DER-encoded ASN.l) 
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11.9.12 SS certificate 

Description: This attribute is a string attribute containing an SS's X.509 User Certificate, as defined in 7.6. 
A summary of the SS-Certificate attribute format is shown below. The fields are transmitted from left to 
right. 



Type 


Length 


Value (string) 


18 


variable. 

Length shall not cause resulting MAC management 
message to exceed the maximum allowed size. 


X.509 SS Certificate (DER-encoded ASN.l) 



11.9.13 Security capabilities 

Description: The Security-Capabilities attribute is a compound attribute whose subattributes identify the 
version of PKM an SS supports and the cryptographic suite(s) an SS supports. 





Length 


Value (compound) 


19 


variable 


The Compound field contains the subattributes as 
defined in Table 374 



Table 374— Security-capabilities subattributes 



Attribute 


Contents 


Cryptographic-Suite-List 


List of supported cryptographic suites 


Version 


Version of Privacy supported 
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11.9.14 Cryptographic suite 



Table 375— Data encryption algorithm identifiers 



Value 


Description 


0 


No data encryption 


1 


CBC-Mode, 56-bit DES 


2 


AES, CCM mode 


3-255 


reserved 


Table 376— Data authentication algorithm identifiers 


Value 


Description 


0 


No data authentication 


1-255 


reserved 


Table 377— TEK encryption algorithm identifiers 


Value 


Description 


0 


reserved 


1 


3-DES EDE with 128-bit key 


2 


RSA with 1024-bit key 


3 


AES with 128-bit key 


4-255 


reserved 



Type 


Length 


Value (uint8,uint8,uint8) 


20 


3 


A 24-bit integer identifying the cryptographic suite 
properties. The most significant byte, as defined in 
Table 375, indicates the encryption algorithm and key 
length. The middle byte, as defined in Table 376 indicates 
the data authentication algorithm. The least significant byte, 
as defined in Table 377, indicates the TEK Encryption 
Algorithm. 
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The allowed cryptographic suites are itemized in Table 378. 



Table 378— Allowed cryptographic suites 



Value 


Description 


0x000001 


No data encryption, no data authentication and 3-DES,128 


0x010001 


CBC-Mode 56-bit DES, no data authentication and 3-DES,128 


0x000002 


No data encryption, no data authentication and RSA, 1024 


0x010002 


CBC-Mode 56-bit DES, no data authentication and RSA, 1024 


0x020003 


CCM-mode AES, no data authentication and AES, 128 


all remaining values 


reserved 



11.9.15 Cryptographic-Suite-List 

This parameter contains a list of supported cryptographic suites. 



Type 


Length 


Value (compound) 


21 


5*n, where n equals number of 
cryptographic suites listed 


A list of cryptographic suites 



11.9.16 Version 



Table 379— Version attribute values 



Value 


Description 


0 


reserved 


1 


PKM (Initial standard release) 


2-255 


reserved 



Type 


Length 


Value (uint8) 


22 


1 


A 1-byte code identifying a version of PKM security as 
defined in Table 379. 
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11.9.17 SA-Descriptor 

Description: The SA-Descriptor attribute is a compound attribute whose subattributes describe 
properties of a Security Association (SA). These properties include the SAID, the SA type, and 
cryptographic suite employed within the SA. 



Table 380— SA-Descriptor subattributes 



Attribute 


Contents 


SAID 


Security Association ID 


SA-Type 


Type of SA 


Cryptographic-Suite 


Cryptographic suite employed within the SA 



Type 


Length 


Value (compound) 


23 


variable 


The Compound field contains the subattributes shown in Table 380. ' 



1 Y 

119.18 SA type 

Description: This attribute identifies the type of SA. Privacy defines three SA types: Primary, Static, 
Dynamic. 



Type 


Length 


Value (uint8) 


24 


1 


A 1 byte code identifying the value of SA-type as defined in Table 381. 




Table 381— SA-type attribute values 






Value 


Description 






0 


Primary 






1 


Static 






2 


Dynamic 






3-127 


reserved 






128-255 


Vendor-specific 
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11.9.19 PKM configuration settings 

This field defines the parameters associated with PKM operation. It is composed of a number of 
encapsulated TLV fields. 



Type 


Length 


Value (compound) 


Scope 


27 


variable 




Auth Reply 



11.9.19.1 Authorize wait timeout 

The value of the field specifies retransmission interval, in seconds, of Authorization Request messages from 
the Authorize Wait state. 



Type 


Length 


Value 


27.1 


4 


Authorize Wait Timeout in seconds 



11.9.19.2 Reauthorize wait timeout 

The value of the field specifies retransmission interval, in seconds, of Authorization Request messages from 
Reauthorize Wait state. 



Type 


Length 


Value 


27.2 


4 


Reauthorize Wait Timeout in seconds 



1 1 .9.1 9.3 Authorization grace time 

The value of this field specifies the grace period for reauthorization, in seconds. 



Type 


Length 


Value 


27.3 


4 


Authorization Grace Time in seconds 



11.9.19.4 Operational wait timeout 

The value of this field specifies the retransmission interval, in seconds, of Key Requests from the 
Operational Wait state. 



Type 


Length 


Value 


27.4 


4 


Operational Wait Timeout in seconds 
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11.9.19.5 Rekey wait timeout 

The value of this field specifies the retransmission interval, in seconds, of Key Requests from the Rekey 
Wait state. 



Type 


Length 


Value 


27.5 


4 


Rekey Wait Timeout in seconds 



11.9.19.6 TEK grace time 

The value of this field specifies grace period, in seconds, for rekeying the TEK. 



Type 


Length 


Value 


27.6 


4 


TEK Grace time in seconds 



11.9.19.7 Authorize reject wait timeout 

The value of this field specifies how long (in seconds) an SS waits in the Authorize Reject Wait state 
receiving an Authorization Reject. 



Type 


Length 


Value 


27.7 


4 


Authorize Reject Wait Timeout in seconds 



11.10 MCA-REQ management message encodings 

The type values used shall be those defined in Table 382. 



Table 382— Multicast assignment request message encodings 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


Multicast CID 


1 


2 




Assignment 


2 


1 


0x00 = Leave multicast group 
0x01 = Join multicast group 


Multicast group 
type 


3 


1 


0 = regular (not AAS), default 

1 = AAS 


Periodic allocation 
parameters 


4 


4 


Byte #0 (LS byte)= m 
Byte #1 = k 
Byte #2 = n 

Byte #3 = Reserved; shall be set to zero 



692 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS IEEE Std 802.16-2004 



Table 382— Multicast assignment request message encodings 



Name 


Type 
(1 byte) 


Length 


Value 
(variable-length) 


Periodic allocation 
type 


5 


1 


0 = REQ region Full 

1 = REQ region Focused 

Applicable for OFDM PHY only! 


Operation 


6 


1 


0 = allocate 

1 = deallocate 


reserved 


7-255 




Reserved for future use 



Parameters m, k have the following meaning: multicast group gets a multicast polling allocation at the end 
of the frame #N if N mod k = m; size of the allocation is n. 

11.11 REP-REQ management message encodings 



Name 


Type 


Length 


Value 


Report request 


1 


variable 


Compound 



The Report Command consists of the following parameters: 



Name 


TVpe 


Length 


Value i 


Report type 


1.1 


1 


Bit #0 = 1 Include DFS Basic report 
Bit #1 = 1 Include CINR report 
Bit #2 = 1 Include RSSI report 

Bit #3-6 <x avg \ in multiples of 1/32 (range [1/32, 16/32]) 
Bit #7 = 1 Include current transmit power report 


Channel number 


1.2 


1 


Physical channel number (see 8.5.1) to be reported on. 
(license-exempt bands only) 


Channel Type 
request 


1.3 


1 


00 = Normal subchannel, 

01 = Band AMC Channel, 

10 = Safety Channel, 

1 1 = Reserved 
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11.12 REP-RSP management message encodings 



Name 


Type 


Length 


Value 


Report 


1 


variable 


Compound 


Channel Type Report in 
WirelessMAN OFDMA 
PHY 


2 


variable 


Compound 


Current transmitted power 


147 


1 


See 8.3.7.4 and 11.1.1 



The report consists of the following parameters (see.also 8.2.2, 8.3.9, or 8.4.11 for details). 



REP-REQ 
Report type 


Name 


Type 


Length 


Value 


bit #0 = 1 


Channel number 


1.1 


1 


Physical channel number (see 8.5.1) to be reported on 


bit #0 = 1 


Start frame 


1.2 


2 


Frame number in which measurement for this channel 
started 


bit #0 = 1 


Duration 


1.3 


3 


Cumulative measurement duration on the channel in 
multiples of T s . For any value exceeding OxFFFFFF, 
report OxFFFFFF 


bit #0=1 


Basic report 


1.4 


1 


Bit #0: WirelessHUMAN detected on the channel 
Bit #1: Unknown transmissions detected on the channel 
Bit #2: Primary User detected on the channel 
Bit #3: Unmeasured. Channel not measured 


bit #1 = 1 


CINR report 


1.5 


2 


1 byte: mean (see also 8.2.2, 8.3.9, 8.4.11) for details) 

1 byte: standard deviation 1 


bit #2= 1 


RSSI report 


1.6 


2 


1 byte: mean (see also 8.2.2, 8.3.9, 8.4.11) for details) 
1 1 byte: standard deviation 



REP-REQ 
Channel Type 
request 


Name 




Length 


Value 


Channel Type = 00 


Normal sub- 
channel Report 


2.1 


1 


First 5 bits for the CINR measurement report 
and the rest for don't care 


Channel Type = 01 


Band AMC 
Report 


2.2 


4 


First 12 bits for the band indicating bitmap and 
Next 25 bits for CINR reports (5 bits per each 
band) 


Channel Type = 10 


Safety Channel 
Report 


2.3 


5 


The first 20 bits for the reported bin indices and 
the next 20 bits for CINR reports (5 bits for 
each bin) 



11.13 Service Flow management encodings 

The following fields define the parameters associated with uplink/downlink scheduling for a service 
is somewhat complex in that it is composed from a number of encapsulated TLV fields. 
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Note that the encapsulated uplink and downlink flow classification configuration setting strings share the 
same subtype field numbering plan, because many of the subtype fields defined are valid for both types of 
configuration settings except service flow encodings. 

Uplink encodings use the type 145. Downlink encodings use the type 146. Entries of the form [145/146] 
indicate the encoding can be applied to either an uplink or downlink service flow. 

Table 383— Service flow encodings 



Type 


Parameter 


1 


Service Flow Identifier 


2 


CID 


3 


Service Class Name 


4 


reserved 


5 


QoS Parameter Set Type 


6 


Traffic Priority 


7 


Maximum Sustained Traffic Rate 


8 


Maximum Traffic Burst 


9 


Minimum Reserved Traffic Rate 


10 


Minimum Tolerable Traffic Rate 


11 


Service Flow Scheduling Type 


12 


Request/Transmission Policy 


13 


Tolerated Jitter 


14 


Maximum Latency 


15 


Fixed-length versus Variable-length SDU Indicator 


16 


SDU Size 


17 


Target SAID 


18 


ARQ Enable 


19 


ARQ_WINDOW_SIZE 


20 


ARQ_RETRY_TIMEOUT - Transmitter Delay 


21 


ARQ_RETRY_TIMEOUT - Receiver Delay 


22 . 


ARQ_BLOCK_LIFETIME 


23 


ARQ_SYNC_LOSS 


24 


ARQ_DELIVER_IN_ORDER 


25 


ARQ_PURGE_TIMEOUT 


26 


ARQ_BLOCK_SIZE 


27 


reserved 


28 


CS Specification 


143 


Vendor-specific QoS Parameter 


99-107 


Convergence Sublayer Types 
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The CC indicates the status for the dynamic service (DSx-xxx) messages. The value may appear i 
Confirmation Code field of a DSx message or as the value of a TLV-encoded error parameter. 

The CC values are specified in Table 384. 



Table 384— CC values 



CC 


Status 


0 


OK/success 


1 


reject-other 


2 


reject-unrecognized-configuration-setting 


3 


reject-temporary / reject-resource 


4 


reject-permanent / reject- admin 


5 


reject-not-owner 


6 


reject- service-flow-not-found 


7 


reject-service-flow-exists 


8 


reject-required-parameter-not-present 


9 


reject-header-suppression j 


10 


reject-unknown-transaction-id 


11 


reject-authentication-failure 


12 


reject- add-aborted 


13 


reject-exceeded-dynamic-service-limit 


14 


reject-not-authorized-for-the-requested-SAID 


15 


reject-fail-to-establish-the-requested-SA 


16 


reject-not-supported-parameter 


17 


reject-not-supported-parameter-value 



In the case CC = "reject-not-supported-parameter" or CC = "reject-not-supported-parameter-value", the 
corresponding TLV(s) may be returned to caller in DSx-RSP message. In the case of CC = "reject-not 
supported-parameter-value," the value field of the returned TLV should contain the closest value that 1 
supported. 
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11.13.1 SFID 

The SFID is used by the BS as the primary reference of a service flow. Only the BS may issue a SFID. It 
uses this parameterization to issue SFIDs in BS-initiated DSA-REQ/DSC-REQ messages and in its DSA- 
RSP/DSC-RSP to SS-initiated DSA-REQ/DSC-REQ messages. The SS specifies the SFID of a service flow 
using this parameter in a DSC-REQ message. 



TVpe 


Length 


Value 


Scope 


[145/146].! 


4 


1^294 967 295 


DSx-REQ 
DSx-RSP 
DSx-ACK 



11.13.2 CID 

The value of this field specifies the CID assigned by the BS to a service flow with a non-null 
AdmittedQosParamSet or ActiveQosParamSet. The 16-bit value of this field is used in bandwidth requests 
and in MAC PDU headers. This field shall be present in a BS-initiated DSA-REQ or DSC-REQ message 
related to establishing an admitted or active service flow. This field shall also be present in DSA-RSP and 
DSC-RSP messages related to the successful establishment of an admitted or active service flow. 

Even though a service flow has been successfully admitted or activated (i.e., has an assigned CID) the SFID 
shall be used for subsequent DSx message signalling as it is the primary handle for a service flow. If a 
service flow is no longer admitted or active (via DSC-REQ), its CID may be reassigned by the BS. 



Type 


Length 


Value 


Scope 


[145/146].2 


2 


CID 


DSx-REQ 
DSx-RSP 
DSx-ACK 



11.13.3 Service Class Name 

The value of this field refers to a predefined BS service configuration to be used for this service flow. 



Type 


Length 


Value 


Scope 


[145/146J.3 


2 to 128 


Null -terminated string of ASCII characters. 

The length of the string, including null -terminator 

may not exceed 128 bytes 


DSx-REQ 
DSx-RSP 
DSx-ACK 



When the Service Class Name is used in a service flow encoding, it indicates that all the unspecified QoS 
parameters of the service flow need to be provided by the BS. It is up to the operator to synchronize the 
definition of Service Class Names in the BS. 
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11 .1 3.4 QoS parameter set type 

This parameter shall appear within every service flow encoding. It specifies the proper application of the 
QoS Parameter Set: to the Provisioned set, the Admitted set, and/or the Active set. When two QoS 
Parameter Sets are the same, a multibit value of this parameter may be used to apply the QoS parameters to 
more than one set. A single message may contain multiple QoS parameter sets in separate type 145/146 
service flow encodings for the same service flow. This allows specification of the QoS Parameter Sets when 
their parameters are different. Bit 0 is the LSB of the Value field. 

For every service flow that is preprovisioned and for every provisioned service flow added after SS 
initialization, there shall be a service flow encoding that specifies a ProvisionedQoSParamSet. This service 
flow encoding, or other service flow encoding(s), may also specify an Admitted and/or Active set. 



Type 


Length 


Value 


Scope 


[145/146].5 


1 


Bit 0: Provisioned Set 
Bit 1: Admitted Set 
Bit 2: Active Set 
Bits 3-7: Reserved 


DSx-REQ 
DSx-RSP 
DSx-ACK 



A BS shall handle a single update to each of the Active and Admitted QoS parameter sets. The ability to 
process multiple service flow encodings that specify the same QoS parameter set is not required and is left as 
a vendor-specific function. If a DSA/DSC contains multiple updates to a single QoS parameter set and the 
vendor does not support such updates, then the BS shall reply with CC 2 (reject-unrecognized- 
configuration- setting) . 



Table 385 lists values used in Dynamic Service messages. 



Table 385— Values used in Dynamic Service messages 



Value 


Messages 


001 


Apply to Provisioned set only 


011 


Apply to Provisioned and Admitted set, and perform admission control 


101 


Apply to Provisioned and Active sets, perform admission control, and 
activate this service flow 


111 


Apply to Provisioned, Admitted, and Active sets; perform admission control; 
and activate this service flow 


000 


Set Active and Admitted sets to Null 


010 


Perform admission control and apply to Admitted set 


100 


Check against Admitted set in separate service flow encoding, perform 
admission control if needed, activate this service flow, and apply to Active 
set 


110 


Perform admission control and activate this service flow, apply parameters to 
both Admitted and Active sets 



69 g Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



IEEE Std 802.16-2004 



1 1 .1 3.5 Traffic priority 

The value of this parameter specifies the priority assigned to a service flow. Given two service flows 
identical in all QoS parameters besides priority, the higher priority service flow should be given lower delay 
and higher buffering preference. For otherwise nonidentical service flows, the priority parameter should not 
take precedence over any conflicting service flow QoS parameter. The specific algorithm for enforcing this 
parameter is not mandated here. 

For uplink service flows, the BS shall use this parameter when determining precedence in request service 
and grant generation, and the SS shall preferentially select contention Request opportunities for Priority 
Request CIDs based on this priority and its Request/Transmission Policy (see 11.13.12). 



Type 


Length 


Value 


Scope 


[145/146].6 


1 


0 to 7 — Higher numbers indicate higher priority 
Default 0 


DSx-REQ 
DSx-RSP 
DSx-ACK 



11.13.6 Maximum sustained traffic rate 

This parameter defines the peak information rate of the service. The rate is expressed in bits per second and 
pertains to the SDUs at the input to the system. Explicitly, this parameter does not include MAC overhead 
such as MAC headers or CRCs. This parameter does not limit the instantaneous rate of the service since this 
is governed by the physical attributes of the ingress port. However, at the SS in the uplink direction, the 
service shall be policed to conform to this parameter, on the average, over time. At the BS in the downlink 
direction, it may be assumed that the service was already policed at the ingress to the network and the BS is 
not required to do additional policing. If this parameter is omitted or set to zero, then there is no explicitly 
mandated maximum rate. This field specifies only a bound, not a guarantee that the rate is available. The 
algorithm for policing to this parameter is left to vendor differentiation and is outside the scope of the 
standard. 



Type 


Length 


Value 


Scope 


[145/146].7 


4 


Rate (in bits per second) 


DSx-REQ 1 

DSx-RSP 

DSx-ACK 



11.13.7 Maximum traffic burst 

This parameter defines the maximum burst size that shall be accommodated for the service. Since the 
physical speed of ingress/egress ports, the air interface, and the backhaul will, in general, be greater than the 
maximum sustained traffic rate parameter for a service, this parameter describes the maximum continuous 
burst the system should accommodate for the service, assuming the service is not currently using any of its 
available resources 
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Type 


Length 


Value 


Scope 


[145/146].8 


4 


Burst size (bytes) 


DSx-REQ 
DSx-RSP 
DSx-ACK 



11.13.8 Minimum reserved traffic rate 

This parameter specifies the minimum rate reserved for this service flow. The rate is expressed in bits per 
second and specifies the minimum amount of data to be transported on behalf of the service flow when 
averaged over time. The specified rate shall only be honored when sufficient data is available for scheduling. 
When insufficient data exists, the requirement imposed by this parameter shall be satisfied by assuring that 
the available data is transmitted as soon as possible. 

The BS shall be able to satisfy bandwidth requests for a service flow up to its Minimum Reserved Traffic 
Rate. If less bandwidth than its Minimum Reserved Traffic Rate is requested for a service flow, the BS may 
reallocate the excess reserved bandwidth for other purposes. The aggregate Minimum Reserved Traffic Rate 
of all service flows may exceed the amount of available bandwidth. The value of this parameter is calculated 
from the byte following the MAC header HCS to the end of the MAC PDU payload. If this parameter is 
omitted, then it defaults to a value of 0 bits per second (i.e., no bandwidth is reserved for the flow). 



Type 


Length 


Value 


Scope 


[145/146].9 


4 


Rate (in bits per second) 


DSx-REQ 
DSx-RSP 
DSx-ACK 



11.13.9 Minimum tolerable traffic rate 

Minimum Tolerable Traffic Rate = R (bits/s) with time base 7(sec) means the following. Let S denote 
additional demand accumulated at the MAC SAP of the transmitter during an arbitrary time interval of the 
length T. Then the amount of data forwarded at the receiver to CS (in bits) during this interval should be not 
less than minimum {5, R * T}. 

In the case of downlink connections, Minimum Tolerable Traffic Rate may be monitored by the BS to make 
decisions on rate change or deletion of the connection in the case of high SDU loss rate. 



Type 


Length 


Value 


Scope 


[145/146].10 


4 


Rate (in bits per second) 


DSx-REQ 
DSx-RSP 
DSx-ACK 
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11.13.10 Vendor-specific QoS parameters 

This allows vendors to encode vendor-specific QoS parameters. The Vendor ID shall be the first TLV 
embedded inside vendor-specific QoS parameters. If the first TLV inside vendor-specific QoS parameters is 
not a Vendor ID, then the TLV shall be discarded (see 11.1.6). 



Type 


Length 


Value 


Scope 


[145/146J.143 


variable 


Compound 


DSx-REQ 
DSx-RSP 
DSx-ACK 



1 1 .1 3.1 1 Service flow scheduling type 

The value of this parameter specifies the scheduling service that shall be enabled for the associated service 
flow. If the parameter is omitted, BE service is assumed. 



Type 


Length 


Value 


Scope 


[145/146]. 11 


1 


0: Reserved 

1: for Undefined (BS implementation-dependent 3 ) 

2: for BE (default) 

3:fornrtPS 

4: for HPS 

5: Reserved 

6:forUGS 

7-255: Reserved 


DSA-REQ 
DSA-RSP 
DSA-ACK 



a The specific implementation-dependent scheduling service type could be defined in a message of Type 
145/146.143 (vendor-specific QoS parameters). 



11.13.12 Request/transmission policy 

The value of this parameter provides the capability to specify certain attributes for the associated service 
flow. These attributes include options for PDU formation and, for uplink service flows, restrictions on the 
types of bandwidth request options that may be used. An attribute is enabled by setting the corresponding bit 
position to 1. For attributes affecting uplink bandwidth request types, a value of zero indicates the default 
actions described in the scheduling service description in 6.3.5 shall be used. A value of one indicates that 
the action associated with the attribute bit overrides the default action. 
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Type 


Length 


Value 


Scope 


[145/146].12 


4 


Bit #0 - Service flow shall not use broadcast bandwidth request 

opportunities. (Uplink only) 
Bit #1 - Reserved; shall be set to zero 

Bit #2 - The service flow shall not piggyback requests with data. 

(Uplink only) 
Bit #3 - The service flow shall not fragment data. 
Bit #4 - The service flow shall not suppress payload headers (CS 

parameter) 

Bit #5 _ The service flow shall not pack multiple SDUs (or frag- 
ments) into single MAC PDUs. 
Bit #6 - The service flow shall not include CRC in the MAC PDU. 
Bit #7 - Reserved; shall be set to zero 


DSA-REQ 
DSA-RSP 
DSA-ACK 



11.13-13 Tolerated jitter 

This parameter defines the maximum delay variation (jitter) for the connection. 



Type 


Length 


Value 


Scope 


[145/146].13 


4 


ms 


DSx-REQ 
DSx-RSP 
DSx-ACK 



11.13.14 Maximum latency 

The value of this parameter specifies the maximum latency between the reception of a packet by the BS or 
SS on its network interface and the forwarding of the packet to its RF Interface. 

If defined, this parameter represents a service commitment (or admission criteria) at the BS or SS and shall 
be guaranteed by the BS or SS. A BS or SS does not have to meet this service commitment for service flows 
that exceed their minimum reserved rate. 



Type 


Length 


Value 


Scope 


[145/146]. 14 


4 


ms 


DSx-REQ 
DSx-RSP 
DSx-ACK 
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11.13.15 Fixed-length versus variable-length SDU indicator 

The value of this parameter specifies whether the SDUs on the service flow are fixed-length or variable- 
length. The parameter is used only if packing is on for the service flow. The default value is 0, i.e., variable- 
length SDUs. 



Type 


Length 


Value 


Scope 1 


[145/146].15 


1 


0 = variable-length SDUs 


DSA-REQ 






1 = fixed-length SDUs 


DSA-RSP 






default = 0 


DSA-ACK 



11.13.16 SDU size 

The value of this parameter specifies the length of the SDU for a fixed-length SDU service flow. This 
parameter is used only if packing is on and the service flow is indicated as carrying fixed-length SDUs. The 
default value is 49 bytes, i.e., VC-switched ATM cells with PHS. The parameter is relevant for both ATM 
and Packet Convergence Sublayers. 



Type 


Length 


Value 


Scope 


[145/146J.16 


1 


Number of bytes. 


DSA-REQ 






default = 49 


DSA-RSP 








DSA-ACK 



11.13.17 Target SAID 

The target SAID parameter indicates the SAID onto which the service flow that is being set up shall be 
mapped. 



Type 


Length 


Value 


Scope 


[145/146J.17 


2 


SAID onto which SF is mapped 


DSA-REQ 
DSA-RSP 



11.13.18 ARQ TLVs for ARQ-enabled connections 
11.13.18.1 ARQ Enable 

This TLV indicates whether or not ARQ use is requested for the connection that is being setup. A value of 0 
indicates that ARQ is not requested and a value of 1 indicates that ARQ is requested. The DSA-REQ shall 
contain the request to use ARQ or not. The DSA-RSP message shall contain the acceptance or rejection of 
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the request. ARQ shall be enabled for this connection only if both sides report this TLV to be non-zero. The 
SS shall either reject the connection or accept the connection with ARQ. 



Type 


Length 


Value 


Scope 


[145/i46].18 
1.18 


1 


0 = ARQ Not Requested/Accepted 

1 = ARQ Requested/Accepted 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 



11.13.18.2 ARQ_WINDOW_SIZE 

This parameter is negotiated upon connection setup or during operation. The DSA-REQ/DSC-REQ message 
shall contain the suggested value for this parameter. The DSA-RSP/DSC-RSP message shall contain the 
confirmation value or an alternate value for this parameter. The smaller of the two shall be used as the 
ARQ_WINDOW_SIZE. 



Type 


Length 


Value 


Scope 


[145/146]. 19 
1.19 


2 


> 0 and < (ARQ_BSN_MODULUS/2) 


DSx-REQ, DSx-RSP 
REG-REQ, REG-RSP 



11.13.18.3 ARQ_RETRY_TIMEOUT 

The ARQ_retry_timeout should account for the transmitter and receiver processing delays and any other 
delays relevant to the system. 

TRANSMITTERJDELAY: This is the total transmitter delay, including sending (e.g., MAC PDUs) and 
receiving (e.g., ARQ feedback) delays and other implementation dependent processing delays. If 
the transmitter'is the BS, it may include other delays such as scheduling and propagation delay. 

RECEIVER_DELAY: This is the total receiver delay, including receiving (e.g., MAC PDUs) and sending 
(e.g., ARQ feedback) delays and other implementation-dependent processing delays. If the 
receiver is the BS, it may include other delays such as scheduling and propagation delay. 

The DSA-REQ and DSA-RSP messages shall contain the values for these parameters, where the receiver 
and transmitter each declare their capabilities. When the DSA handshake is completed, each party shall cal- 
culate ARQ_RETRY_TIMEOUT to be the sum of TRANSMITTER.DEL AY and RECEIVER.DELAY. 



Type 


Length 


Value 


Scope 


[145/146].20 
1.20 


2 


TRANSMITTER J3ELAY 
0-655350 (10 \i$ granularity) 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 


[145/146].21 
1.21 


2 


RECEIVER J)ELAY 
0-655350 (10 \ls granularity) 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 
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11.13.18.4 ARCLBLOCKJJFETIME 

The DSA-REQ message shall contain the value of this parameter as defined by the parent service flow. If 
this parameter is set to 0, then the ARQ_BLOCK_LIFETIME value shall be considered infinite. 



1>pe 


Length 


Value 


Scope 


[145/146].22 
1.22 


2 


0 = Infinite 

1-655350 (10 \is granularity) 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 



11.13.18.5 ARQ_SYNC_LOSS_TIMEOUT 

The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_SYNC_LOSS_TIMEOUT value 
shall be considered infinite. 



Type 


Length 


Value 


Scope 


[145/146J.23 
1.23 


2 


0 = Infinite 

1-655350 (10 (is granularity) 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 



11.13.18.6 ARQ_DELIVERJN_ORDER 

The DSA-REQ message shall contain the value of this parameter. This TLy indicates whether or not data is 
to be delivered by the receiving MAC to its client application in the order in which the data was handed off 
to the originating MAC. 



Type 


Length 


Value 


Scope 


[145/146J.24 
1.24 


1 


0 - Order of delivery is not preserved 

1 - Order of delivery is preserved 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 



If this flag is not set, then the order of delivery is not preserved. If this flag is set (to 1), then the order of 
delivery is preserved. 

11.13.18.7 ARQ_RX_PURGE_TIWIEOUT 

The DSA-REQ message shall contain the value of this parameter as defined by the parent service flow. If 
this parameter is set to 0, then the ARQ_RX_PURGE__TIMEOUT value shall be considered infinite. 



Type 


Length 


Value 


Scope 


[145/146J.25 
1.25 


2 


0 = Infinite 

1-65535 (10 jas granularity) 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 
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11.13.18.8 ARQ_BLOCK_SIZE 

This value of this parameter specifies the size of an ARQ block. This parameter shall be established by 
negotiation during the connection creation dialog. 

The requester includes its desired setting in the REQ message. The receiver of the REQ message shall take 
the smaller of the value it prefers and value in the REQ message. This minimum value is included in the RSP 
message and becomes the agreed upon length value. 

Absence of the parameter during a DSA dialog shall indicate the originator of the message desires the 
maximum value. 



Type 


Length 


Value 


Scope 


[145/146].26 
1.26 


2 


0 - Reserved 

1-2040 = Desired/Agreed size in bytes 
2041-65535 = Reserved 


DSA-REQ, DSA-RSP 
REG-REQ, REG-RSP 



11.13.19 CS specific service flow encodings 
11.13.19.1 CS specification 

This parameter specifies the CS that the connection being set up shall use. 



Type 


Length 


Value 


Scope 


[145/146] .28 


1 


0: No CS 

1: Packet, IPv4 

2: Packet, IPv6 

3: Packet, 802.3/Ethernet 

4: Packet, 802. IQ VLAN 

5: Packet, IPv4 over 802.3/Ethernet 

6: Packet, IPv6 over 802.3/Ethernet 

7: Packet, IPv4 over 802. IQ VLAN 

8: Packet, IPv6 over 802. IQ VLAN 

9: ATM 

10-255 Reserved 


DSA-REQ 
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11.13.19.2 CS parameter encoding rules 

Each CS defines a set of parameters that are encoded within a subindex under the "est" values listed below. 
In the cases of IP over IEEE 802.x, the relevant IP and IEEE 802.x parameters shall be included in the 
DSx-REQ message. 



est 


CS 


99 


ATM 


100 


Packet, IPv4 


101 


Packet, IPv6 


102 


Packet, 802.3/Ethernet 


103 


Packet, 802. 1Q VLAN 


104 


Packet IPV4 over 802.3/Ethernet 


105 


Packet IPV6 over 802.3/Ethernet 


106 


Packet IPV4 over 802. 1Q VLAN 


107 


Packet IPV6 over 802. 1Q VLAN 



11.13.19.3 Packet CS encodings for configuration and MAC messaging 

The following TLV encoded parameters shall be used in Dynamic Service messages. The CS specific type is 
denoted in the tables in the following subclauses by the variable "est," which takes its value from the table in 
11.13.19.2 (e.g., 100, 101, ...) depending upon the exact packet CS used for the service. 

11.13.19.3.1 QoS-related encodings 

The following TLV encodings shall be used in registration messages and Dynamic Service messages to 
encode parameters for packet classification and scheduling. 

The following configuration settings shall be supported by all SSs that are compliant with this specification. 

11.13.19.3.2 Classifier DSC action 

When received in a DSC-REQ, this indicates the action to be taken with this classifier. 



Type 


Length 


Value 


[145/146].cst.l 


1 


0 — DSC Add Classifier 

1 — DSC Replace Classifier j 

2 — DSC Delete Classifier 
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11.13.19.3.3 Classifier error parameter set 

This field defines the parameters associated with Classifier Errors. 



Type 


Length 


Value 


[145/146].cst.2 


variable 


Compound 



A Classifier Error Parameter Set is defined by the following individual parameters: Packet Classifier Rule 
Index, Errored Parameter, Error Code, and Error Message. 

The Classifier Error Parameter Set is returned in DSA-RSP and DSC-RSP messages to indicate the 
recipient's response to a Classifier establishment request in a DSA-REQ or DSC-REQ message. 

On failure, the sender shall include one Classifier Error Parameter Set for each failed Classifier requested in 
the DSA-REQ or DSC-REQ message. Classifier Error Parameter Set for the failed Classifier shall include 
the Error Code and Errored Parameter and may include an Error Message. If some Classifier Sets are 
rejected but other Classifier Sets are accepted, then Classifier Error Parameter Sets shall be included for only 
the rejected Classifiers. On success of the entire transaction, the RSP or ACK message shall not include a 
Classifier Error Parameter Set. 

Multiple Classifier Error Parameter Sets may appear in a DSA-RSP or DSC-RSP message, since multiple 
Classifier parameters may be in error. A message with even a single Classifier Error Parameter Set shall not 
contain any other protocol Classifier Encodings (e.g., IP, IEEE Std 802.1D-2004, IEEE Std 802. 1Q, 2003 
Edition). 

A Classifier Error Parameter Set shall not appear in any DSA-REQ or DSC-REQ messages. 
11.13.19.3.3.1 Errored parameter 

The value of this parameter identifies the subtype of a requested Classifier parameter in error in a rejected 
Classifier request. A Classifier Error Parameter Set shall have exactly one Errored Parameter TLV within a 
given Classifier Encoding. 



Subtype 


Length 


Value 


[145/146].cst.2.1 


n \ 


Classifier Encoding Subtype in Error 



If the length is 1, then the value is the single-level subtype where the error was found; e.g., 1 indicates an 
invalid Change Action. If the length is 2, then the value is the multilevel subtype where the error was found; 
e.g., 3-3 indicates an invalid IP Protocol value. 
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11.13.19.3.3.2 Error code 

This parameter indicates the status of the request. A nonzero value corresponds to the CC as described in 
11.13.1. A Classifier Error Parameter Set shall have exactly one Error Code within a given Classifier 
Encoding. 



Subtype 


Length 


Value 


[145/146] .cst.2.2 


1 


CC except OK(0) 



A value of OK(0) indicates that the Classifier request was successful. Since a Classifier Error Parameter Set 
applies only to errored parameters, this value shall not be used. 

11.13.19.3.3.3 Error message 

This subtype is optional in a Classifier Error Parameter Set. If present, it indicates a text string to be 
displayed on the SS console and/or log that further describes a rejected Classifier request. A Classifier Error 
Parameter Set may have zero or one Error Message subtypes within a given Classifier Encoding. 



Subtype 


Length 


Value 


[145/146].cst.2.3 


n 


Null-terminated string of ASCII characters 

The length of the string, including null-terminator 

may not exceed 128 bytes 



11.13.19.3.4 Packet classification rule 

This compound parameter contains the parameters of the classification rule. All parameters pertaining to a 
specific classification rule shall be included in the same Packet Classification Rule compound parameter. 



Type 


Length 


Value 


[145/146].cst.3 


variable 


Compound 



11.13.19.3.4.1 Classifier rule priority 

The value of the field specifies the priority for the Classifier, which is used for determining the order of the 
Classifier. A higher value indicates higher priority. 

Classifiers may have priorities in the range 0-255 with the default value being 0. 



Type 


Length 


Value 


[145/146].cst.3.1 


1 


0-255 
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11.13.19.3.4.2 IP Type of service/differentiated services codepoint (DSCP) range and mask 

The values of the field specify the matching parameters for the IP type of service/DSCP (EETF RFC 2474) 
byte range and mask. An IP packet with IP type of service (ToS) byte value "ip-tos" matches this parameter 
if tos-low < (ip-tos AND tos-mask) < tos-high. If this field is omitted, then comparison of the IP packet ToS 
byte for this entry is irrelevant. 



Type 


Length 


Value 


[145/146].cst.3.2 


3 


tos-low, tos-high, tos-mask 



11.13.19.3.4.3 Protocol 

The value of the field specifies a list of matching values for the IP Protocol field. For IPv6 (IETF RFC 
2460), this refers to next header entry in the last header of the IP header chain. The encoding of the value 
field is that defined by the IANA document "Protocol Numbers.'* If this parameter is omitted, then 
comparison of the IP header Protocol field for this entry is irrelevant. 



Type 


Length 


Value 


[145/146].cst.3.3 


n 


protl, prot2,...prot n 



11.13.19.3.4.4 IP masked source address 

This parameter specifies a list of IP source addresses (designated "src ( ") and their corresponding address 
masks (designated "smask ")• An IP packet with IP source address "ip-src" matches this parameter if src; = 
(ip-src AND smask;) for any i from 1 to n. If this parameter is omitted, then comparison of the IP packet 
source address for this entry is irrelevant. 



Type 


Length 


Value 


[145/146].cst.3.4 


n*8 (IPv4) or 
n*32 (IPv6) 


src l5 smask srq, smask,-,..., src rt , smask n 



11.13.19.3.4.5 IP destination address 

This parameter specifies a list of IP destination addresses (designated "dst/') and their corresponding 
address masks (designated "dmask,"). An IP packet with IP destination address "ip-dst" matches this 
parameter if dst, = (ip-dst AND dmask,) for any i from 1 to n. If this parameter is omitted, then comparison 
of the IP packet destination address for this entry is irrelevant. 



Type 


Length 


Value 


[145/146].cst.3.5 


n*8 (IPv4) or 
/i*32 (IPv6) 


dsti, dmask!,..., dst,-, dmask,-,..., dst rt , dmask^ 
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11.13.19.3.4.6 Protocol source port range 

The value of the field specifies a list of nonoverlapping ranges of protocol source port values. Classifier 
rules with port numbers are protocol specific; i.e., a rule on port numbers without a protocol specification 
shall not be defined. An IP packet with protocol port value "src-port" matches this parameter if src-port is 
greater than or equal to sportlow and src-port is less than or equal to sporthigh. If this parameter is omitted, 
the protocol source port is irrelevant. This parameter is irrelevant for protocols without port numbers. 



Type 


Length 


Value 


[145/146].cst.3.6 


n*4 


sportlow 1, sporthigh 2,..., sportlow n, 
sporthigh n 



11.13.19.3.4.7 Protocol destination port range 

The value of the field specifies a list of nonoverlapping ranges of protocol destination port values. Classifier 
rules with port numbers are protocol specific; i.e., a rule on port numbers without a protocol specification 
shall not be defined. An IP packet with protocol port value "dst-port" matches this parameter if dst-port is 
greater than or equal to dportlow and dst-port is less than or equal to dporthigh. If this parameter is omitted 
the protocol destination port is irrelevant. This parameter is irrelevant for protocols without port numbers. 



Type 


Length 


Value 


[145/1 46] .cst.3.7 


n*4 


dportlow 1, dporthigh 2,...,dportlow /i, 
dporthigh n 



11.13.19.3.4.8 IEEE 802.3/Ethernet destination MAC address 

This parameter specifies a list of MAC destination addresses (designated "dst/') and their corresponding 
address masks (designated "msk ")• An IEEE 802.3/Ethernet packet with MAC destination address 
"etherdst" corresponds to this parameter if dst, = (etherdst AND msk,) for any i from 1 to n. If this parameter 
is omitted, then comparison of the IEEE 802.3/Ethernet destination MAC address for this entry is irrelevant. 



Type 


Length 


Value 


[145/146]xst.3.8 


**12 


dsti, msk lv .., dst/, msk,-,..., dst rt , msk n 



11.13.19.3.4.9 IEEE 802.3/Ethernet source MAC address 

This parameter specifies a list of MAC source addresses (designated "src") and their corresponding address 
masks (designated "msk"). An IEEE 802.3/Ethernet packet with MAC source address "ethersrc" 
corresponds to this parameter if src, = (ethersrc AND msk,) for any i from 1 to n. If this parameter is omitted, 
then comparison of the IEEE 802.3/Ethernet source MAC address for this entry is irrelevant. 
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Type 


Length 


Value 


[145/146].cst.3.9 


71*12 


src^ msk lv .., srq, msk,-,..., src n , msk„ 



11.13.19.3.4.10 Ethertype/IEEE 802.2 SAP 

The format of the Layer 3 protocol ID in the Ethernet packet is indicated by type, eprotl, and eprot2 as 
follows: 

If type = 0, the rule does not use the Layer 3 protocol type as a matching criteria. If type = 0, eprotl , eprot2 
are ignored when considering whether a packet matches the current rule. 

If type = 1, the rule applies only to SDUs that contain an Ethertype value. Ethertype values are contained in 
packets using the DEC-Intel-Xerox (DIX) encapsulation or the Sub-Network Access Protocol (SNAP) 
encapsulation (IEEE 802.2, IETF RFC 1042) format. If type = 1, then eprotl, eprot2 gives the 16 bit value 
of the Ethertype that the packet shall match in order to match the rule. 

If type = 2, the rule applies only to SDUs using the IEEE 802.2 encapsulation format with a Destination 
Service (DSAP) other than OxAA (which is reserved for SNAP). If type = 2, the lower 8 bits of the eprotl, 
eprot2 shall match the DSAP byte of the packet in order to match the rule. 

If the Ethernet SDU contains an IEEE 802.1D and IEEE 802.1Q Tag header (i.e., Ethertype 0x8100), this 
object applies to the embedded Ethertype field within the IEEE 802. ID and IEEE 802.1 Q header. 

Other values of type are reserved. If this TLV is omitted, then comparison of either the Ethertype or 
IEEE 802.2 DSAP for this rule is irrelevant. 



Type 


Length 


Value 


[145/146].cst.3.10 


3 


type, eprotl, eprot2 



11.13.19.3.4.11 IEEE 802.1 D User_Priority 

The values of this field specify the matching parameters for the IEEE 802. ID user_priority bits. An Ethernet 
packet with IEEE 802. ID user_priority value "priority" matches these parameters if priority is greater than 
or equal to pri-low and priority is less than or equal to pri-high. If this field is omitted, then comparison of 
the IEEE 802. ID user_priority bits for this entry is irrelevant. 

If this parameter is specified for an entry, then Ethernet packets without IEEE 802. 1Q encapsulation shall 
NOT match this entry. If this parameter is specified for an entry on an SS that does not support forwarding of 
IEEE 802. 1Q encapsulated traffic, then this entry shall not be used for any traffic. 



Type 


Length 


Value 


[145/146].cst.3.11 


2 


pri-low, pri-high 

Valid Range: 0-7 for pri-low and pri-high 
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11.13.19.3.4.12 IEEE 802.1Q VLANJD 

The value of the field specifies the matching value for the IEEE 802. 1Q vlan_id bits. Only the first (i.e. left- 
most) 1 2 bits of the specified vlan _jd field are significant; the final four bits shall be ignored for comparison. 
If this field is omitted, then comparison of the IEEE 802.1Q vlanjd bits for this entry is irrelevant. 

If this parameter is specified for an entry, then Ethernet packets without IEEE 802. 1Q encapsulation shall 
not match this entry. If this parameter is specified for an entry on an SS that does not support forwarding of 
IEEE 802.1Q encapsulated traffic, then this entry shall not be used for any traffic. 



Type 


Length 


Value 


[145/146].cst.3.12 


2 


vlan_idl, vlan_id2 



11.13.19.3.4.13 Associated PHSI 

The Associated PHSI has a value between 1 and 255, which shall mirror the PHSI value of a PHS rule. 
Packets matching the Packet Classification Rule containing the Associated PHSI parameter shall undergo 
PHS according to the corresponding PHS rule. 



Type 


Length 


Value 


[145/146].cst.3.13 


1 


Index value 



11.13.19.3.4.14 Packet Classifier Rule Index 

The Packet Classifier Rule Index identifies a Packet Classifier Rule. The Packet Classifier Rule Index is 
unique per service flow. 



Type 


Length 


Value 


[145/146].cst.3.14 


2 


Packet Classifier Rule Index 



11.13.19.3.4.15 Vendor-specific classifier parameters 

This allows vendors to encode vendor-specific classifier parameters. The Vendor ID shall be the first TLV 
embedded inside vendor- specific classifier parameters. If the first TLV inside vendor-specific classifier 
parameters is not a Vendor ID, then the TLV shall be discarded (see 11.1.6). 



Type 


Length 


Value 


[145/146].cst.3.143 


variable 


Compound 
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11.13.19.3.5 PHS DSC action 

When received in a DSC-REQ, this indicates the action that shall be taken with this PHS byte string. 



Type 


Length 


Value 


[145/146].cst.4 


1 


0 — Add PHS Rule 

1 — Set PHS Rule 

2 — Delete PHS Rule 

3 — Delete all PHS Rules 



The "Set PHS Rule" command is used to add the specific TLVs for an undefined PHS rule. It shall NOT be 
used to modify existing TLVs. 

When deleting all PHS Rules, any corresponding PHSI shall be ignored. 
An attempt to add a PHS Rule that already exists is an error condition. 
11.13.19.3.6 PHS error parameter set 

This field defines the parameters associated with PHS errors. 



Type 


Length 


Value 


[145/146].cst.5 


variable 


Compound field 



A PHS Error Parameter Set is defined by the following individual parameters: 

a) PHSI 

b) Errored Parameter 

c) Error Code 

d) Error Message 

The PHS Error Parameter Set is returned in DSA-RSP and DSC-RSP messages to indicate the recipient's 
response to a PHS Rule establishment request in a DSA-REQ or DSC-REQ message. 

On failure, the sender shall include one PHS Error Parameter Set for each failed PHS Rule requested in the 
DSA-REQ or DSC-REQ message. PHS Error Parameter Set for the failed PHS Rule shall include the Error 
Code and Errored Parameter and may include an Error Message. If some PHS Rule Sets are rejected but 
other PHS Rule Sets are accepted, then PHS Error Parameter Sets shall be included for only the rejected 
PHS Rules. On success of the entire transaction, the RSP or ACK message shall not include a PHS Error 
Parameter Set. 

Multiple PHS Error Parameter Sets may appear in a DSA-RSP or DSC-RSP message, since multiple PHS 
parameters may be in error. A message with even a single PHS Error Parameter Set shall not contain any 
other protocol PHS Encodings (e.g., IP or IEEE Std 802.1D-2004/IEEE Std 802.1Q, 2003 Edition). 



A PHS Error Parameter Set shall not appear in any DSA-REQ or DSC-REQ messages. 
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11.13.19.3.6.1 Errored parameter 

The value of this parameter identifies the subtype of a requested PHS Parameter in error in a rejected PHS 
request. A PHS Error Parameter Set shall have exactly one Errored Parameter TLV within a given PHS 
Encoding. 



Type 


Length 


Value 


[145/146].cst.5.1 


1 


PHS j 
Encoding Subtype in Error 



11.13.19.3.6.2 Error code 

This parameter indicates the status of the request. A nonzero value corresponds to the CC as described in 
11.13.1. A PHS Error Parameter Set shall have exactly one Error Code within a given PHS Encoding. 



Type 


Length 


Value 


[145/146].cst.5.2 


1 


CC except OK(0) as specified in 
Table 384 



A value of OK(0) indicates that the PHS request was successful. Since a PHS Error Parameter Set only 
applies to errored parameters, this value shall not be used. 

1 1 .1 3.1 9.3.6.3 Error message 

This subtype is optional in a PHS Error Parameter Set. If present, it indicates a text string to be displayed on 
the SS console and/or log that further describes a rejected PHS request. A PHS Error Parameter Set may 
have zero or one Error Message subtypes within a given PHS Encoding. 



Type 


Length 


Value 


[145/146].cst.5.3 


n 


Null-terminated string of ASCII characters 



The length n may not exceed 128 including the terminating NULL. 
11.13.19.3.7 PHS Rule 

This field defines the parameters associated with a PHS Rule. 



Type 


Length 


Value 


[145/146].cst.6 


n 
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11.13.19.3.7.1 PHSI 

The PHSI has a value between- 1 and 255, which uniquely references the suppressed byte string. The index is 
unique per service flow. The uplink and downlink PHSI values are independent of each other. 



Type 


Length 


Value 


[145/146].cst.6.1 


1 


Index value 



11.13.19.3.7.2 PHSF 

The PHSF is a string of bytes containing the header information to be suppressed by the sending CS and 
reconstructed by the receiving CS. The most significant byte of the string corresponds to the first byte of the 
CS-SDU. 



Type 


Length 


Value 


[145/146].cst.6.2 


n 


String of bytes suppressed 



The length n shall always be the same as the value for PHSS. 
11.13.19.3.7.3 PHSM 

The value of this field is used to interpret the values in the PHSF. It is used at both the sending and receiving 
entities on the link. The PHSM allows fields, such as sequence numbers or checksums (which vary in value), 
to be excluded from suppression with the constant bytes around them suppressed. 



Type 


Length 


Value 


[145/146].cst.6.3 


n 


bit 0: 0 = don't suppress first byte of the suppression field 
1 = suppress first byte of the suppression field 

bit 1 : 0 = don't suppress second byte of the suppression field 
1 = suppress second byte of the suppression field 

bit x: 0 = don't suppress (jc+1) byte of the suppression field 
1 = suppress (jc+1) byte of the suppression field 



The length n is ceiling (PHSS/8). Bit 0 is the MSB of the Value field. The value of each sequential bit in the 
PHSM is an attribute for the corresponding sequential byte in the PHSF. 

If the bit value is a "1," the sending entity should suppress the byte, and the receiving entity should restore 
the byte from its cached PHSF. If the bit value is a "0," the sending entity should not suppress the byte, and 
the receiving entity should restore the byte by using the next byte in the packet. 

If this TLV is not included, the default is to suppress all bytes. 
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11.13.19.3.7.4 PHSS 

The value of this field is the total number of bytes in the header to be suppressed and then restored in a 
service flow that uses PHS. 



Type 


Length 


Value 


[145/146].cst.6.4 


1 


Number of bytes in the suppression string 



This TLV is used when a service flow is being created. For all packets that get classified and assigned to a 
service flow with PHS enabled, suppression shall be performed over the specified number of bytes as 
indicated by the PHSS and according to the PHSM. If this TLV is not included in a service flow definition, 
or is included with a value of 0 bytes, then PHS is disabled. A nonzero value indicates PHS is enabled. 

11.13.19.3.7.5 PHSV 

The value of this field indicates to the sending entity whether or not the packet header contents are to be 
verified prior to performing suppression. If PHSV is enabled, the sender shall compare the bytes in the 
packet header with the bytes in the PHSF that are to be suppressed as indicated by the PHSM. 



Type 


Length 


Value 


[145/146].cst.6.5 


1 


0 = verify 

1 = don't verify 



If this TLV is not included, the default is to verify. Only the sender shall verify suppressed bytes. If 
verification fails, the Payload Header shall NOT be suppressed. 

11.13.19.3.7.6 Vendor-specific PHS parameters 

This allows vendors to encode vendor- specific PHS parameters. The Vendor ID shall be the first TLV 
embedded inside vendor-specific PHS parameters. If the first TLV inside vendor-specific PHS parameters is 
not a Vendor ID, then the TLV shall be discarded. 



Type 


Length 


Value 


[145/146].cst.6.143 


variable 


Compound 



1 1 .1 3.1 9.3.8 IPv6 Flow label 

The value of this field specifies a list of matching values for the IPv6 Flow label field. As the flow label field 
has a length of 20 bits, the first 4 bits of the most significant byte shall be set to 0x0 and disregarded. 



Type 


Length 


Scope 


[145/146].[101/105/107].3.15 


n*3 


Flow Label #'l...Flow label#n 
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11.13.19.4 ATM CS Encodings for Configuration and MAC Messaging 

The TLV encodings listed in 11.13.194.1 through 11.13.19.4.3 shall be used in the configuration file, in SS 
registration requests (when applicable), and in Dynamic Service messages (when applicable). All ATM 
specific TLVs are prefixed to begin with a Type value of [145/146J.99. 

11.13.19.4.1 ATM switching encoding 

This field defines the switching methodology for the service. If the field = 0, at least one VPI/VCI Classifier 
pair shall be defined for classifying the service. If the field = 1, exactly one VPI Classifier and zero or one 
VCI Classifier shall be specified for classifying the service. If the field = 2, exactly one VPI Classifier and 
one VCI Classifier shall be defined for classifying the service. If the field = 0, PHS is not allowed and the 
SDU size TLV shall equal 52. If the field = 1 and PHS is on for the service, the SDU size TLV shall equal 
51; otherwise it shall be set equal to 52. If the field = 2 and PHS is on for the service, the SDU size TLV shall 
equal 49; otherwise it shall be set equal to 52. 



Type 


Length 


Value 


[145/146].99.1 


1 


0 = no switching methodology applied 

1 = VP switching 

2 = VC switching ! 



11.13.19.4.2 ATM Classifier TLV 

This field defines an ATM classifier. It is a compound TLV used to describe the VPI and associated VCIs for 
ATM classification. 



Type 


Length 


Value 


[145/146].99.2 


variable 


Compound 



It shall have the following form: 



Field 


Note 


ATM Classifier ID 


Always present 


VPI Classifier 


Always present except for DSC Change action 
deleting classifier 


VCI Classification 


0 or more instances (number apparent from ATM 
Classifier length field) if VPI Classifier is 
present 
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11.13.19.4.2.1 VPI classifier 

This field defines the VPI on which to classify ATM cells for the service flow. 



Type 


Length 


Value 


[145/146J.99.2.1 


2 


8-bit or 12-bit VPI field value 



1 1 .1 3.1 9.4.2.2 VCI classification 

This field defines the VCI on which to classify ATM cells for the service flow. 
This TLV shall immediately follow the VPI TLV with which it is associated. 



Type 


Length 


Value 


[145/146].99.2.2 


2 


16-bit VCI field value 



11.13.19.4.2.3 ATM Classifier ID 

This field is used to identify an ATM classifier. 



Type 


Length 


Value 


[145/146].99.2.3 


16 


16-bit classifier ID 



11.13.19.4.3 ATM Classifier DSC Action 

When received in a DSC-REQ message, this indicates the action to be taken on a classifier. If the action TLV 
is Add or Replace, the action is followed by a complete ATM Classifier compound TLV. If the action is 
delete, the action TLV is followed by the ATM Classifier compound TLV composed only of the ATM 
Classifier ID TLV 



Type 


Length 


Value 


[145/146].99.3 


1 


0 - DSC Add Classifier 

1 - DSC Replace Classifier 

2 - DSC Delete Classifier 
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11.13.19.4.4 ATM Classifier Error Parameter Set 

This field defines the parameters associated with ATM classifier errors. 



Type 


Length 


Value 


[145/146].99.4 


variable 


Compound 



The contents of the compound structure shall be identical to the encoding for the Classifier Error Parameter 
Set for packet services specified in 11.13.19.3.3. 
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12. System profiles 

This clause defines system profiles that list sets of features to be used in typical implementation cases. Each 
profile is assigned an identifier for use in such documents as PICS proforma statements. Features specified 
in the standard as optional may be listed in a profile as "required" or "conditionally required." Profiles do 
not change "mandatory" status if specified in the standard itself. Any feature that is specified in the standard 
as optional and does not appear in certain profile is optional for the profile, thus absence of this feature in 
specific implementation does not affect conformance to the profile. Optional features shall be implemented 
as specified in the standard. 

12.1 WirelessMAN-SC (10-66 GHz) system profiles 

This subclause defines system profiles for systems operating with the WirelessMAN-SC air interface. 



Table 386— Profile definitions 



Identifier 


Description 


profMl 


Basic ATM MAC profile 


profM2 


Basic packet MAC profile 


profPl 


25 MHz channel PHY profile 


profPlf 


25 MHz channel PHY profile - FDD 


profPlt 


25 MHz channel PHY profile - TDD j 


profP2 


28 MHz channel PHY profile 


profP2f 


28 MHz channel PHY profile - FDD 


profP2t 


28 MHz channel PHY profile - TDD 



12.1.1 WirelessMAN-SC MAC system profiles 

This subclause defines MAC profiles for systems operating with the WirelessMAN-SC air interface. 
12.1.1.1 Basic ATM MAC system profile 

Profile identifier: profMl. 
Mandatory features: 

— Support of PVCs. 

— Support of VC-switched connections. 

— Support of VP-switched connections. 

— ATM PHS is mandatory as a capability, but may be turned on or off on a per connection basis. 

— IPv4 on the Secondary Management connection. 

— Packing of multiple ATM cells into a single MAC PDU is mandatory as a capability, but may be 
turned on or off on a per-connection basis. 

— SDU fragmentation on the Primary Management and Secondary management connections. 
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Conditionally Mandatory features: 

If nrtPS or BE services are supported, then the SS responding to broadcast polling is mandatory. 

— If multicast polling groups are supported, multicast polling must be supported. 

12.1.1.2 Basic Packet MAC system profile 

Profile identifier: profM2. 
Mandatory features: 

— Support of provisioned connections. 

— IPv4 support on transport connection. 

— Classification of packets in the SS based on the incoming physical port. 

— Reception of multiple SDUs packed into a single MAC PDU is mandatory as a capability, but may 
be turned on or off on a per connection basis. 

— Fragmentation of SDUs is mandatory as a capability, but may be turned on or off on a per-connection 
basis. 

Conditionally Mandatory features: . 

— If nrtPS or BE services are supported, then the SS responding to broadcast polling is mandatory. 

— If multicast polling groups are supported, multicast polling must be supported. 

12.1.1.3 Conventions for MAC Management messages for profiles profMI and profM2 

The following rules shall be followed when reporting parameters in MAC Management messages: 

— Service Class Names should not be used. 

— No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSA-RSP and DSC- 
RSP messages. 

— No TLVs besides HMAC Tuples shall be reported back in DSA-ACK messages. 

— DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU 
Indicator, SDU Size, ATM Switching, or Convergence Sublayer Specification TLVs. 

12.1.1.4 MAC Management message Parameter Transmission Order 

The following subclauses define the order in which systems meeting profiles profMI and profM2 shall 
transmit the TLV encoded parameters for mandatory features in the respective messages. Systems 
implementing either profile shall only include the parameters listed under the respective message in its 
transmission of these messages plus any parameters necessary for optional features. Parameters for optional 
features shall occur after those listed for support of mandatory features. Parameters with defined default 
values should be omitted if the desired value coincides with the default one. PHY specific messages are 
described in 12.1.2. 

12.1.1.4.1 DCD 

The parameters of the DCD message are PHY profile specific. , 

12.1.1.4.2 DL-MAP 

This message contains no TLV encoded information. 
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12.1.1.4.3 UCD 

The parameters of the DCD message are PHY profile specific. 

12.1.1.4.4 UL-MAP 

This message contains no TLV encoded information. 

12.1.1.4.5 RNG-REQ 

— Requested downlink Burst Profile 

— SS MAC Address 

— Ranging Anomalies 

12.1.1.4.6 RNG-RSP 

If ranging status equals "success" or "continue": 

— Ranging Status 

— Timing Adjust (default to 0) 

— Power Adjust (default to 0) 

— Downlink operational Burst profile (only if changed) 

— SS MAC Address (only on CID 0x0000) 

— Basic CID (only on CID 0x0000) 

— Primary Management CID (only on CID 0x0000) 

— Uplink Channel Override (only if allowed by PHY profile) 

If ranging status equals "abort": 

— Ranging Status 

— SS MAC Address (only on CID 0x0000) 

— Downlink frequency Override (if needed) 

12.1.1 .4.7 REG-REQ 

— Vendor ID Encoding (optional) 

— Uplink CID Support 

— PKM Flow Control (default = no limit) 

— DSx Flow Control (default = no limit) 

— MCA Flow Control (default = no limit) 

— IP version (default = IPv4) 

— MAC CRC support (default = support) 

— Multicast Polling Group CID support (default = 4) 

— Convergence Sublayer Support (1 instance for each CS supported) 

— Maximum number of classifiers (default = 0, no limit) 

— PHS support (default = 0, no PHS support) 

— HMAC Tuple 

12.1.1.4.8 REG-RSP 

— Secondary Management CID 

— Uplink CID Support 

— Vendor ID Encoding (if present in REG-REQ) 

— PKM Flow Control (if present in REG-REQ or changed from default) 
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— DSx Flow Control (if present in REG-REQ or changed from default) 

— MCA Flow Control (if present in REG-REQ or changed from default) 

— IP version (if present in REG-REQ or changed from default) 

— MAC CRC support (if present in REG-REQ or changed from default) 

— Multicast Polling Group CID support (if present in REG-REQ or changed from default) 

— Vendor-specific information (Compound, only allowed if Vendor ID present in REG-REQ, and 
extensions provided) 

— Vendor ID 

— Vendor-specific extensions 

— HMAC Tuple 

1 2.1 .1 .4.9 PKM-REQ: Auth Info 

— CA-Certificate 

12.1.1.4.10 PKM-REQ: Auth Request 

— SS-Certificate 

— Security Capabilities 

— Version (default =1) 

— Cryptographic-Suite-List (default is that both no encryption and 56-bit DES are supported, no data 
authentication, and 3-DES EDE with 128-bit key) 

— SAID 

12.1.1.4.11 PKM-REQ: Key Request 

— Key Sequence Number 

— SAID 

— HMAC-Digest 

12.1.1.4.12 PKM-RSP: SA Add 

— Key-Sequence-Number 

— SA-Descriptor(s) 

— SAID 

— SA-Type 

— Cryptographic Suite 

— HMAC-Digest 

12.1.1.4.13 PKM-RSP: Auth Reply 

— AUTH-Key 

— Key-Lifetime 

— Key-Sequence-Number 

— SA-Descriptor(s) 

— SAID 

— SA-Type 

— Cryptographic Suite 

12.1.1.4.14 PKM-RSP: Auth Reject 

— Error Code 

— Display String (optional) 
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12.1.1.4.15 PKM-RSP: Key Reply 

— Key Sequence Number 

— SAID 

— TEK-Parameters (Older) 

— TEK 

— Key Lifetime 

— Key Sequence Number 

— CBC-IV 

— TEK-Parameters (Newer) 

— TEK 

— Key Lifetime 

— Key Sequence Number 

— CBC-IV 

— HMAC-Digest 

12.1.1.4.16 PKM-RSP: Key Reject 

— Key Sequence Number 

— SAID 

— Error Code 

— Display String (optional) 

— HMAC-Digest 

12.1.1.4.17 PKM-RSP: Auth Invalid 

— Error Code 

— Display String (optional) 

12.1.1.4.18 PKM-RSP: TEK Invalid 

— Key Sequence Number 

— SAID 

— Error Code 

— Display String (optional) 

— HMAC-Digest 

12.1.1.4.19 DSA-REQ— BS Initiated Service Addition 

— Uplink Service Parameters 

— Service Flow ID 

— Transport CID 

— Target SAID 

— QoS Parameter Set Type 

— Service Flow Scheduling Type 

— Request/Grant Transmission Policy 

— Convergence Sublayer Specification 

— Fixed vs Variable Length SDU Indicator (default = variable) 

— SDU Size (required if fixed, forbidden if variable SDU) 

— Maximum Sustained Traffic Rate 

— Minimum Reserved Traffic Rate (default = 0 for BE, Max Sust Rate for UGS, required for rtPS and 
nrtPS) 

— Maximum Traffic Burst (required for rtPS and nrtPS, excluded otherwise) 

— Traffic Priority (optional, BE only) 
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— Tolerated Jitter (optional) 

— Maximum Latency (optional) 

— Convergence Sublayer Specific Parameters (see 12.1.1.5 and 12.1.1.6) 

— Vendor-specific QoS Parameters 

— Downlink Service Parameters 

— Service Flow ID 

— Transport CID 

— Target SAID 

— QoS Parameter Set Type 

— Service Flow Scheduling Type 

— Request/Grant Transmission Policy 

— Convergence Sublayer Specification 

— Fixed vs. Variable Length SDU Indicator (default = variable) 

— SDU Size (required if fixed, forbidden if variable SDU) 

— Convergence Sublayer Specific Parameters (see 12.1.1.5 and 12.1.1.6) 

— Vendor-specific QoS Parameters 

— HMAC Tuple 

12.1-1 .4.20 DSA-RSP— BS Initiated Service Addition 

— Uplink Service Parameters 

— Service Flow Error Parameter Set(s) (one per errored parameter) 

Errored Parameter 
Error Code 

Error Message (optional) 

— Downlink Service Parameter(s) 

— Service Flow Error Parameter Set(s) (one per errored parameter) 

Errored Parameter 
Error Code 

Error Message (optional) 

— HMAC Tuple 

12.1.1.4.21 DSA-ACK 

— HMAC Tuple 

12.1.1.4.22 DSC-REQ — BS Initiated Service Change 

— Uplink Service Parameters 

— Service Row ID 

— Transport CID 

— QoS Parameter Set Type 

— Maximum Sustained Traffic Rate 

— Minimum Reserved Traffic Rate (default = 0 for BE, Max Sust Rate for UGS, required for 
nrtPS) 

— Maximum Traffic Burst (required for rtPS and nrtPS, excluded otherwise) 

— Traffic Priority (optional, BE only) 

— Tolerated Jitter (optional) 

— Maximum Latency (optional) 

— Convergence Sublayer Specific Parameters (see 1 2. 1 . 1 .5 and 1 2. 1 . 1 .6) 

— Vendor-specific QoS Parameters 

— Downlink Service Parameters 

— Service Flow ID 

— Transport CID 
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— QoS Parameter Set Type 

— Convergence Sublayer Specific Parameters (see 12.1.1.5 and 12.1.1.6) 

— Vendor-specific QoS Parameters 

— HMAC Tuple 

12.1.1.4.23 DSC-RSP— BS Initiated Service Change 

— Uplink Service Parameters 

— Service Flow Error Parameter Set(s) (one per errored parameter) 

Errored Parameter 
Error Code 

Error Message (optional) 

— Downlink Service Parameter(s) 

— Service Flow Error Parameter Set(s) (one per errored parameter) 

Errored Parameter 
Error Code 

Error Message (optional) 

— HMAC Tuple 

12.1.1.4.24 DSC-ACK 

— HMAC Tuple 

12.1.1.4.25 DSD-REQ 

— HMAC Tuple 

12.1.1.4.26 DSD-RSP 

— HMAC Tuple 

12.1.1.4.27 MCA-REQ 

— Multicast CID 

— Assignment 

12.1.1.4.28 MCA-RSP 

Message contains no TLV encoded information 

12.1.1.4.29 DBPC-REQ 

Message contains no TLV encoded information 

12.1.1.4.30 DBPC-RSP 

Message contains no TLV encoded information 

12.1.1.4.31 RES-CMD 

— HMAC Tuple 
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12.1.1.4.32 SBC-REQ 

— WirelessMAN-SC PHY SS Demod Support 

— WirelessMAN-SC PHY SS Modulator Support 

— WirelessMAN-SC PHY SSdownlink FEC Types 

— WirelessMAN-SC PHY SS uplink FEC Types 

— Bandwidth Allocation Support 

12.1.1.4.33 SBC-RSP 

— WirelessMAN-SC PHY SS Demod Support 

— WirelessMAN-SC PHY SS Modulator Support 

— WirelessMAN-SC PHY SS downlink FEC Types 

— WirelessMAN-SC PHY SS uplink FEC Types 

12.1.1.4.34 CLK-CMP 

The message contains no TLV encoded information. 

12.1.1 .4.35 DREG-CMD 

— HMAC Tuple 

12.1.1.4.36 DSX-RVD 

The message contains no TLV encoded information. 

12.1.1.4.37 TFTP-CPLT 

— HMAC Tuple 

12.1.1.4.38 TFTP-RSP 

The message contains no TLV encoded information. 
12.1.1.5 Message parameters specific to profMI 

The following subclauses define the order in which systems meeting profile profMI shall transmit the TLV 
encoded parameters specific to the ATM CS. Parameters with defined default values should be omitted if the 
desired value coincides with the default one. 

12.1.1.5.1 ATM CS Parameters for DSA-REQ — BS Initiated 

— ATM Switching 

— ATM Classifier Rule(s) (default = don't classify) 

— ATM Classifier ID 

— VPI Classifier 

— VCI Classifier(s) (must follow associated VPI, default = don't classify on VCI) 

12.1.1.5.2 ATM CS Parameters for DSA-RSP — BS Initiated 

— None 
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12.1.1.5.3 ATM CS Parameters for DSC-REQ — BS Initiated 

— ATM Classifier Change Action 

— ATM Classifier Rule(s) (default = don't classify) 

— ATM Classifier ID 

— VPI Classifier 

— VCI Classifier(s) (must follow associated VPI, default = don't classify on VCI) 

12.1.1.5.4 ATM CS Parameters for DSC-RSP— BS Initiated 

— None 

12.1.1.6 Message parameters specific to profM2 

12.1.1.6.1 Packet CS Parameters for DSA-REQ — BS Initiated 

— Packet Classification Rule(s) (uplink service flows only, default is no classification) 

— Classifier Rule ID 

— Classifier Rule Priority (default to 0) 

— IP Type of Service/DSCP (only for IP CSs, default = don't classify on this) 

— Protocol (only for IP CSs, default = don't classify on this) 

— IP Masked Source Address (only for IP CSs, default = don't classify on this) 

— IP Destination Address (only for IP CSs, default = don't classify on this) 

— Protocol Source Port Range (only for IP CSs, default = don't classify on this) 

— Protocol Destination Port Range (only for IP CSs, default = don't classify on this) 

— Ethernet Destination MAC Address (only for Ethernet CSs, default = don't classify on this) 

— Ethernet Source MAC Address (only for Ethernet CSs, default = don't classify on this) 

— Ethertype/IEEE 802.2 SAP (only for Ethernet CSs, default = don't classify on this) 

— IEEE 802. ID User Priority (only for VLAN CSs, default = don't classify on this) 

— IEEE 802. 1 Q VLAN_ID (only for VLAN CSs, default = don't classify on this) 

— Associated PHSI (default is no PHS for this classifier match) 

— Vendor-specific Classifier Parameters 

— PHSRule(s) 

— PHSI 

— PHSS 

— PHSF 

— PHSM (default is suppress all bytes of the suppression field) 

— PHSV (default is verify) 

— Vendor-specific PHS Parameters 

12.1.1.6.2 Packet CS Parameters for DSA-RSP — BS Initiated 

— Packet Classification Rule(s) (uplink service flows only, default is no classification) 

— Classifier Error Parameter Set(s) (one per errored parameter) 

Classifier Rule ID 
Errored Parameter 
Error Code 

Error Message (optional) 

— PHSRule(s) 

— PHS Error Parameter Set(s) (one per errored parameter) 

— PHSI 

Errored Parameter 
Error Code 

Error Message (optional) 
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12.1.1.6.3 Packet CS Parameters for DSC-REQ — BS Initiated 

— Classifier Dynamic Service Change Action(s) 

— Packet Classification Rule(s) (uplink service flows only, 1 per Action) 

— Classifier Rule ID 

— Classifier Rule Priority (default to 0) 

— IP Type of Service/DSCP (only for IP CSs, default = don't classify on this) 

— Protocol (only for IP CSs, default = don't classify on this) 

— IP Masked Source Address (only for IP CSs, default = don't classify on this) 

— IP Destination Address (only for IP CSs, default = don't classify on this) 

— Protocol Source Port Range (only for IP CSs, default = don't classify on this) 

— Protocol Destination Port Range (only for IP CSs, default = don't classify on this) 

— Ethernet Destination MAC Address (only for Ethernet CSs, default = don't classify on this) 

— Ethernet Source MAC Address (only for Ethernet CSs, default = don't classify on this) 

— Ethertype/IEEE 802.2 SAP (only for Ethernet CS s, default = don't classify on this) 

— IEEE 802.1D User Priority (only for VLAN CSs, default = don't classify on this) 

— IEEE 802. 1Q VLANJD (only for VLAN CSs, default = don't classify on this) 

— Associated PHSI (default is no PHS for this classifier match) 

— Vendor-specific Classifier Parameters 

— PHS Dynamic Service Change Action 

— PHS Rule(s) (1 per Action) 

— PHSI 

— PHSS 

— PHSF 

— PHSM (default is suppress all bytes of the suppression field) 

— PHSV (default is verify) 

— Vendor-specific PHS Parameters 

12.1.1.6.4 Packet CS Parameters for DSC-RSP— BS Initiated 

— Uplink Service Parameters 

— Service Flow Error Parameter Set(s) (one per errored parameter) 

Errored Parameter 
Error Code 

Error Message (optional) 

— Downlink Service Parameter(s) 

— Service Flow Error Parameter Set(s) (one per errored parameter) 

Errored Parameter 
Error Code 

Error Message (optional) 
12.1.2 WirelessMAN-SC PHY Profiles 

This subclause defines PHY profiles for systems operating with the WirelessMAN-SC PHY. 
12.1.2.1 WirelessMAN-SC 25 MHz Channel PHY Profile 

Profile identifier: profPl. 
Mandatory features: 

— Frame Duration of 1 ms 

— QPSK and QAM- 16 in the DL 

— QPSK in the UL 
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— Roll-off Factor = 0.25 

— RS outer codes with t e {0, 4, 8, 10, 12}. 

— Fixed and shortened last code word operation. 

— RS block lengths of 6-255. 

— 20 MB d symbol rate 

— 5000 PS per frame 

SSs implementing profPl shall meet the minimum SS performance requirements listed in Table 387. 



Table 387 — SS Minimum Performance requirements for profPl 



Capability 


Minimum performance 


Tx Dynamic range 


>40 dB 


Rx Dynamic Range 


>40 dB for QPSK 


Tx RMS Power Level at Maximum Power Level Setting for 
QPSK 


> 15 dBm 


Tx Power Level minimum adjustment step 


0.5 dB 


Tx Power level adjustment step accuracy 
0.5dB < Step size < 2dB 


monotonic 


Tx Power level adjustment step accuracy 
2dB < Step size < 5dB 


±2dB 


Tx Power level adjustment step accuracy 
Step size > 5 dB 


±3dB 


Peak-to-peak symbol jitter, referenced to the previous sym- 
bol zero crossing of the transmitted waveform, as percentage 
of the nominal symbol duration when measured over a 
period of 2 seconds 


2% 


Tx burst timing step size 


± 0.25 of a symbol 


Tx burst timing step accuracy 


±0.125 of a symbol 


Spectral mask (OOB) 


Local regulation 


Ramp up/ramp down time 


< 24 symbols 


Output noise power spectral density when Tx is not 
transmitting 


< -80 dBm/MHz 


Modulation accuracy when measured with an ideal receiver 
without an equalizer for QPSK 


12% 


Modulation accuracy when measured with an ideal receiver 
without an equalizer for 16-QAM 


6% 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for QPSK 


10% 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for 16-QAM 


3% 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for 64- QAM 


1.5% 


BER performance threshold for QPSK, BER=10" 3 


-94 + 101og(25) dBm 
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Capability 


Minimum performance 


BER performance threshold for 16-QAM, BER=10" 3 


-87 + 101og(25) dBm 


BER performance threshold for 64-QAM, BER=10" 3 


-79 + 101og(25) dBm 


BER performance threshold for QPSK, BER=10^ 


-90 + 101og(25) dBm 


BER performance threshold for 16-QAM, BER=10 -6 


-83 + 101og(25) dBm 


BER performance threshold for 64-QAM, BER=10^ 


-74 + 101og(25) dBm 


Transition time from Tx to Rx and from Rx to Tx 


TDD: 2 us 
H-FDD: 20 us 
FDD: n/a 


1 st adjacent channel interference at BER=10" 3 for 3 dB 
degradation C7I for OPSK 


-9 dB 


1 st adjacent channel interference at BER=10" 3 for 3 dB 
degradation C/I for 16-OAM 


-2dB 


1 st adjacent channel interference at BER=10" 3 for 3 dB 
depradation CA for 64-OAM 

\J\J cLl ft Vf till *LT a ' V-^/X IU1 T 


+5dB 


1 st adjacent channel interference at BER=10" 3 for 1 dB 
degradation CA for OPSK 


-5dB 


1 st adjacent channel interference at BER=10~ 3 for 1 dB 
degradation C/I for 16-OAM 


+2 dB 


1 st adjacent channel interference at BER=10~ 3 for 1 dB 
degradation C/T for 64-OAM 

UCgl aUuUUll V_*/x ivi V/ i N^niTi 


+9dB 


1 st adjacent channel interference at BER=10" j6 for 3 dB deg- 
radation C/T for OPSK 


-5 dB 


I st adjacent channel interference at BER=10~^ for 3 dB 

degradation C/I for 16-OAM 


+2dB 


1 st adjacent channel interference at BER=10" 6 for 3 dB 

Hporadatinn C/I for 64-OAM 


+9 dB 


1 st adjacent channel interference at BER=10" 6 for 1 dB 

degradation CA for OPSK 


-1 dB 


1 st adjacent channel interference at BER=10 -6 for 1 dB 

dearadation CA for 16-OAM 


+6 dB 


1 st adjacent channel interference at BER=10~^ for 1 dB 

df amdatinn CA for 64-OAM 


+13 dB 


2 nd adjacent channel interference at BER=10~ 3 for 3 dB 

dearadation CA for OPSK 


-34 dB 


2 nd adjacent channel interference at BER=10" 3 for 3 dB 
degradation CA for 16-QAM 


-27 dB 


2 nd adjacent channel interference at BER=10" 3 for 3 dB 
degradation CA for 64-QAM 


-20 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation CA for QPSK 


-30 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation CA for 16-QAM 


-22 dB 
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Table 387— SS Minimum Performance requirements for profPI (continued) 



Capability 


Minimum performance 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10^ for 3 dB 
degradation C/I for QPSK 


-30 dB 


2 nd adjacent channel interference at BER=10^ for 3 dB 
degradation C/I for 16-QAM 


-23 dB 


2 nd adjacent channel interference at BER=10" 6 for 3 dB 
degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10^ for 1 dB 
degradation C/I for QPSK 


-26 dB 


2 nd adjacent channel interference at BER=10~^ for 1 dB 
degradation C/I for 16-QAM 


-20 dB 


2 nd adjacent channel interference at BER=10" 6 for 1 dB 
degradation C/I for 64-QAM 


-12 dB 


Tx Power Level absolute accuracy 


±6dB 



BSs implementing profPI shall meet the minimum transmitter performance requirements listed in 
Table 388. The receiver shall meet the minimum performance requirements in Table 389. 



Table 388— BS Tx minimum performance requirements for profPI 



Capability 


Minimum performance 


Peak-to-peak symbol jitter, referenced to the previous 
symbol zero crossing of the transmitted waveform, as 
percentage of the nominal symbol duration when measured 
over a period of 2 seconds 


2% 


Tx RF frequency 


10-66 GHz 


Tx RF frequency accuracy 


±io*icr 6 


Spectral mask (OOB) 


Local regulation 


Spurious 


Local regulation 


Ramp up/ramp down time 


< 24 symbols 


Modulation accuracy when measured with an ideal receiver 
without an equalizer for QPSK 


12% 


Modulation accuracy when measured with an ideal receiver 
without an equalizer for 16-QAM 


6% 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for QPSK 


10% 
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Table 388— BS Tx minimum performance requirements for profPI (continued) 



Capability 


Minimum performance 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for 16-QAM 


3% 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for 64-QAM 


1.5% 



Table 389— BS Rx minimum performance for prof P1 



Capability 


Minimum performance 


Dynamic Range 


27 dB for QPSK 


BER performance threshold for QPSK, BER=10"° 


-94 + 101og(25) dBm 


BER performance threshold for 16-QAM, BER=10" 3 


-87 + 101og(25) dBm 


BER performance threshold for 64-QAM, BER=10 -3 


-79 + 101og(25) dBm 


BER performance threshold for QPSK, BER=10"^ 


— vu + luiogizjj ucm 


BER performance threshold for 16-QAM, BER= 10"* 


-83 + 101og(25) dBm 


BER performance threshold for 64-QAM, BER=10~ 6 


-74 + 101og(25) dBm 


1 adjacent channel interference at bfcK-iu ior 3 au 
degradation C/I for QPSK 


-9 dB 


1 adjacent channel interierence at duk-iu ior j od 
degradation C/I for 16-QAM 


-2 dB 


1 adjacent channel interierence at dek- iu ior o ur> 
degradation C/I for 64-QAM 


+5 dB 


1 ct «• . i i :_i--f ai .fl«/,a r»f D CD l fV~^ fr\r 1 rlR 

1 adjacent channel interierence at dek-iu ror i ud 
degradation C/I for QPSK 


-5 dB 


1 st adjacent channel interference at BER=10~ 3 for 1 dB 
degradation C/I for 16-QAM 


+2 dB 


1 st adjacent channel interference at BER=1(T 3 for 1 dB 
degradation C/I for 64-QAM 


+9dB 


1 st adjacent channel interference at BER=10^ for 3 dB 
degradation C/I for QPSK 


-5 dB 


1 st adjacent channel interference at BER=10" j6 for 3 dB 
degradation C/I for 16-QAM 


+2 dB 


1 st adjacent channel interference at BER=10 -6 for 3 dB 
degradation C/I for 64-QAM 


+9dB 


1 st adjacent channel interference at BER=10~^ for 1 dB 
degradation C/I for QPSK 


-ldB 


1 st adjacent channel interference at BER=10 -6 for 1 dB 
degradation C/I for 16-QAM 


+6 dB 


1 st adjacent channel interference at BER=10~* for 1 dB 
degradation C/I for 64-QAM 


+13 dB 
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Table 389— BS Rx minimum performance for profPI (continued) 



Capability 


Minimum performance 


2 nd adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for QPSK 


-34 dB 


2 nd adjacent channel interference at BER=10" 3 for 3 dB 
degradation C/I for 16-QAM 


-27 dB 


2 nd adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for 64-QAM 


-20 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for QPSK 


-30 dB j 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for 16-QAM 


-22 dB 


2 nd adjacent channel interference at BER=10~ 3 for 1 dB 
degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10" 6 for 3 dB 
degradation C/I for QPSK 


-30 dB 


2 nd adjacent channel interference at BER=10^ for 3 dB 
degradation C/I for 16-QAM 


-23 dB 


2 nd adjacent channel interference at BER=10" 6 for 3 dB 
degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10~ 6 for 1 dB 
degradation C/I for QPSK 


-26 dB 


2 nd adjacent channel interference at BER=10~ 6 for 1 dB 
degradation C/I for 1 6-QAM 


-20 dB 


2 nd adjacent channel interference at BER=10~ 6 for 1 dB 
degradation C/I for 64-QAM 


-12 dB 



12.1.2.1.1 FDD Specific WirelessMAN-SC 25 MHz Channel PHY Profile Features 

Profile identifier: profPlf. 
Mandatory features: 

— FDD operation 

— BS must respect half-duplex nature of half-duplex SSs 

12.1.2.1.2 TDD Specific WirelessMAN-SC 25 MHz Channel PHY Profile Features 
Profile identifier: profPlt. 

Mandatory features: 

— TDD operation 

12.1.2.2 WirelessMAN-SC 28 MHz Channel PHY Profile 
Profile identifier: profP2. 
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Mandatory features: 

— Frame Duration of 1 ms 

— QPSK and QAM- 16 in the DL 

— QPSK in the UL 

— Roll-off Factor = 0.25 

— RS outer codes with t e {0, 4, 8, 10, 12}. 

— Fixed and shortened last code word operation 

— RS block lengths of 6-255 

— 22.4 MBd symbol rate 

— 5600 PS per frame 

SSs implementing profP2 shall meet the minimum SS performance requirements as listed in Table 390. 



Table 390— SS Minimum performance for profP2 



Capability 


Minimum performance 


Tx Dynamic range 


>40 dB 


Rx Dynamic Range 


> 40 dB for QPSK 


Tx RMS Power Level at Maximum Power Level Setting for 
QPSK 




Tx Power Level minimum adjustment step 


U.J ur> 


Tx Power level adjustment step accuracy 
Step size [0.5, 2) dB 


monotonic 


Tx Power level adjustment step accuracy 
Step size [2, 5) dB 


±2dB 


Tx Power level adjustment step accuracy 

OlCp MiC C- J UD 


± 3 dB 


Peak-to-peak symbol jitter, referenced to the previous 
symbol zero crossing of the transmitted waveform, as 
percentage of the nominal symbol duration when measured 
over a 2 second period 


2% 


Tx burst timing step size 


± 0.25 of a symbol 


Tx burst timing step accuracy 


± 0.125 of a symbol 


Spectral mask (OOB) 


Local regulation 


Ramp up/ramp down time 


< 24 symbols 


Output noise power spectral density when Tx is not 
transmitting 


< -80 dBm/MHz 


Modulation accuracy when measured with an ideal receiver 
without an equalizer for QPSK 


12% 


Modulation accuracy when measured with an ideal receiver 
without an equalizer for 16-QAM 


6% 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for QPSK 


10% 


Modulation accuracy when measured with an ideal. receiver 
with an equalizer for 16-QAM 


3% 
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Table 390 — SS Minimum performance for profP2 (continued) 



Capability 


Minimum performance 


Modulation accuracy when measured with an ideal receiver 
with an equalizer for 64-QAM 


1.5% 


BER performance threshold for QPSK, BER=10" 3 


-94+ 101og(28)dBm 


BER performance threshold for 16-QAM, BER=10~ 3 


-87 + 101og(28) dBm 


BER performance threshold for 64-QAM, BER=10* 3 


-79+ 101og(28)dBm 


BER performance threshold for QPSK, BER^O" 6 


-90+ 101og(28) dBm 


BER performance threshold for 16-QAM, BER=10" 6 


-83+ 101og(28) dBm 


BER performance threshold for 64-QAM, BER=10" 6 


-74+ 101og(28) dBm 


Transition time from Tx to Rx and from Rx to Tx 


TDD: 2 us 
H-FDD: 20 us 
FDD: n/a 


1 st adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for QPSK 


-9 dB 


1 st adjacent channel interference at BER=10" 3 for 3 dB 
degradation C/I for 16-QAM 


-2 dB 


1 st adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for 64-QAM 


+5 dB 


1 st adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for QPSK 


-5dB 


1 st adjacent channel interference at BER=10~ 3 for 1 dB 
degradation C/I for 1 6-QAM 


+2 dB 


1 st adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for 64-QAM 


+9dB 


1 st adjacent channel interference at BER=10 -6 for 3 dB 
degradation C/I for QPSK 


-5dB 


1 st adjacent channel interference at BER=10"^ for 3 dB 
degradation C/I for 1 6-QAM 


+2 dB 


1 st adjacent channel interference at BER=10" 6 for 3 dB 
degradation C/I for 64-QAM 


+9dB 


1 st adjacent channel interference at BER=10~ 6 for 1 dB 
degradation C/I for QPSK 


-1 dB 


1 st adjacent channel interference at BER=10" 6 for 1 dB 
degradation C/I for 16-QAM 


+6 dB 


1 st adjacent channel interference at BER=10 -6 for 1 dB 
degradation C/I for 64-QAM 


+13 dB ] 
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Table 390— SS Minimum performance for profP2 (continued) 



Capability 


Minimum performance 


2 nd adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for QPSK 


-34 dB 


2 nd adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for 16-QAM 


-27 dB 


2 nd adjacent channel interference at BER=10~ 3 for 3 dB 
degradation C/I for 64-Q AM 


-20 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for QPSK 


-30 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for 16-QAM 


-22 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 dB 
degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10^ for 3 dB 
degradation C/I for QPSK 


-30 dB 


2 nd adjacent channel interference at BER=10^ for 3 dB 
degradation C/I for 16-QAM 


-23 dB 


2 nd adjacent channel interference at BER=10~* for 3 dB 
degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10^ for 1 dB 
degradation C/I for QPSK 


-26 dB 


2 nd adjacent channel interference at BER=10"^ for 1 dB 
degradation C/I for 16-QAM 


-20 dB 


2 nd adjacent channel interference at BER=10" 6 for 1 dB 
degradation C/I for 64-QAM 


-12 dB 


Tx Power Level absolute accuracy 


±6dB 



BSs implementing profP2 shall meet the minimum transmitter performance requirements listed in 
Table 391. The receiver shall meet the minimum performance requirements in Table 392. 



Table 391— BS Tx minimum performance for profP2 



Capability 


Minimum performance 


Peak-to-peak symbol jitter, referenced to the previous 
symbol zero crossing of the transmitted waveform, as per- 
centage of the nominal symbol duration when measured 
over a period of 2 seconds 


2% 


Tx RF frequency 


10-66 GHz 


Tx RF frequency accuracy 


± \ono~ 6 
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Table 391— BS Tx minimum performance for profP2 (continued) 



Spectral mask (OOB) 


local regulation 


Spurious 


local regulation 


Ramp up/ramp down time 


< 24 symbols 


Modulation accuracy when measured with an ideal 
receiver without an equalizer for QPSK 


12% 


Modulation accuracy when measured with an ideal 
receiver without an equalizer for 16-QAM 


6% 


Modulation accuracy when measured with an ideal 
receiver with an equalizer for QPSK 


10% 


Modulation accuracy when measured with an ideal 
receiver with an equalizer for 16-QAM 


3% 


Modulation accuracy when measured with an ideal 
receiver with an equalizer for 64-QAM 


1.5% 



Table 392— BS Rx minimum performance for profP2 



Capability 


Minimum performance 


Dynamic Range 


27 dB for QPSK 


BER performance threshold for QPSK, BER=10~ 3 


-94+ 101og(28) dBm 


BER performance threshold for 16-QAM, BER=10" 3 


-87 + 101og(28)dBm 


BER performance threshold for 64-QAM, BER=10~ 3 


-79 + 101og(28) dBm 


BER performance threshold for QPSK, BER=10^ 


-90+ 101og(28)dBm 


BER performance threshold for 16-QAM, BER=10" 6 


-83 + 101og(28)dBm i 


BER performance threshold for 64-QAM, BER=10~* 


-74+ 101og(28) dBm 


1 st adjacent channel interference at BER=10~ 3 for 3 
dB degradation C/l for QPSK 


-9 dB 


1 st adjacent channel interference at BER=10" 3 for 3 
dB degradation C/I for 16-QAM 


-2 dB 


1 st adjacent channel interference at BER=10~ 3 for 3 
dB degradation C/I for 64-QAM 


+5.dB 


1 st adjacent channel interference at BER=10~ 3 for 1 
dB degradation C/I for QPSK 


-5 dB 


1 st adjacent channel interference at BER=10" 3 for 1 
dB degradation C/I for 16-QAM 


+2dB 


1 st adjacent channel interference at BER=10" 3 for 1 
dB degradation C/I for 64-QAM 


+9 dB 


1 st adjacent channel interference at BER=10~ 6 for 3 
dB degradation C/I for QPSK 


-5 dB 


1 st adjacent channel interference at BERslO -6 for 3 
dB degradation C/I for 16-QAM 


+2dB 
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Table 392— BS Rx minimum performance for profP2 (continued) 



1 st adjacent channel interference at BER=10* 6 for 3 
dR degradation C/I for 64-OAM 


+9 dB 


1 st adjacent channel interference at BER^IO" 6 for 1 
HR degradation C/I for OPSK 


-IdB 


1 st adjacent channel interference at BER=10"^ for 1 
dR degradation C/I for 16-OAM 


+6 dB 


1 st adjacent channel interference at BER=10"^ for 1 
dR degradation C/I for 64-OAM 


+13 dB 


2 nd adjacent channel interference at BER=10" 3 for 3 
HR degradation C/I for OPSK 


-34 dB 


2 nd adjacent channel interference at BER=10" 3 for 3 
dR degradation C/I for 16-OAM 


-27 dB 


2 nd adjacent channel interference at BER=10" 3 for 3 
HR He gradation C/I for 64-OAM 


-20 dB 


2 nd adjacent channel interference at BER=10~ 3 for 1 

HR HpgraHatinn C/I for OPSK 


-30 dB 


2 nd adjacent channel interference at BER=10" 3 for 1 
HR degradation C/I for 16-OAM 


-22 dB 


2 nd adjacent channel interference at BER=10~ 3 for 1 

HR degradation C/I for 64-OAM 


-16 dB 


2 nd adjacent channel interference at BER=10" j6 for 3 

HR degradation C/I for OPSK 


-30 dB 


2 nd adjacent channel interference at BER=10^ for 3 

HR dpcrradatinn C/T for 1 6-OAM 


-23 dB 


2 nd adjacent channel interference at BER=10 -6 for 3 
dB degradation C/I for 64-QAM 


-16 dB 


2 nd adjacent channel interference at BER=10"' 6 for 1 
dB degradation C/I for QPSK 


-26 dB 


2 nd adjacent channel interference at BER=10^ for 1 
dB degradation C/I for 16-QAM 


-20 dB 


2 nd adjacent channel interference at BER=10" 6 for 1 
dB degradation C/I for 64-QAM 


-12 dB 



12.1.2.2.1 FDD Specific WirelessMAN-SC 28 MHz Channel PHY Profile Features 

Profile identifier: profP2f. 
Mandatory features: 

— FDD operation 

— BS must respect half-duplex nature of half -duplex SSs 

12.1.2.2.2 TDD Specific WirelessMAN-SC 28 MHz Channel PHY Profile Features 

Profile identifier: profP2t. 
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. Mandatory features: 

— TDD operation 

12.1.2.3 Conventions for MAC Management messages for profiles profPI and profP2 

The following rules shall be followed when reporting parameters in MAC Management messages for 
systems operating PHY profiles profPI or profP2: 

— Symbol Rate, Frequency, and Roll-off Factor shall not be reported in UCD messages. 

— BCC Code Type shall not be reported in UCD messages. 

— Frame Duration shall not be reported in DCD messages. 

— BCC Code Type shall not be reported in DCD messages. 

— Uplink Channel Override shall not be reported in RNG-RSP messages. 

12.1.2.4 UCD and DCD parameter transmission order for profPI and profP2 

The following subclauses define the order in which systems meeting profiles profPI and profP2 shall 
transmit the TLV encoded parameters in the respective messages. Systems implementing either profile shall 
only include the parameters listed under the respective message in its transmission of these messages. 
Parameters with defined default values should be omitted if the desired value coincides with the default one. 

12.1.2.4.1 DCD 

— BS Transmit Power 

— PHY Type 

— Power Adj Rule 

— Downlink Burst Profile(s) 

— Modulation Type 

— FEC Code Type (default to RS only if omitted) 

— RS Information Bytes 

— RS parity bytes 

— Last Codeword Length (default to shortened if omitted) 

— Exit Threshold 

— Entry Threshold 

— Preamble Present (default to "not present" if omitted) 

12.1.2.4.2 UCD 

— SS Transition Gap (default to 24 symbols if omitted) 

— Power Adjustment Rule 

— Contention-based Reservation Timeout 

— Uplink Burst Profile(s) 

— Modulation Type 

— Preamble Length 

— FEC Code Type (default to RS only) 

— RS Information Bytes 

— RS Parity Bytes 
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— Randomizer Seed 

— Last Codeword Length (default to shortened) 
12.1.2.5 Initial Ranging IE usage for profPI and profP2 

BSs implementing profPI or profP2 shall include exactly one Initial Ranging IE in the UL-MAP for each 
intended opportunity for an SS to perform Initial Ranging. 

12.2 WirelessMAN-SCa and WirelessHUMAN(-SCa) system profiles 

This subclause specifies system profiles for systems using the WirelessMAN-SCa PHY. Its scope includes 
both licensed and license-exempt (WirelessHUMAN) operation. 

A WirelessMAN-SCa system profile contains four components: MAC profiles (12.2.1), a power class 
profile (12.2.2), a PHY profile with an associated duplexing selection (12.2.3), and an RF channelization 
profile (12.2.4). 

12.2.1 WirelessMAN-SCa MAC System Profiles 

This subclause defines MAC profiles for systems operating with the WirelessMAN-SCa air interface. 

12.2.1.1 Basic ATM MAC System Profile 

Profile identifier: profM4. 
Mandatory features: 

— Support of PVCs 

— Support of VC-switched connections 

— Support of VP-switched connections 

— ATM payload header suppression is mandatory as a capability, but may be turned on or off on a per 
connection basis 

— IPv4 on the Secondary Management connection 

— Packing of multiple ATM cells into a single MAC PDU is mandatory as a capability, but may be 
turned on or off on a per connection basis 

— SDU fragmentation on the Primary Management and Secondary management connections 

— ARQ is mandatory as a capability, but may be turned on or off on a per connection basis 

— Handling of undecodable transmissions in an initial ranging slot 

Conditionally mandatory features: 

— If nrtPS or BE services are supported, then the SS responding to broadcast polling is mandatory 

— If multicast polling groups are supported, multicast polling must be supported 

12.2.1.2 Basic Packet MAC System Profile 

Profile identifier: profMS. 
Mandatory features: 

— Support of provisioned connections 

— IPv4 support on transport connection 

— Classification of packets in the SS based on the incoming physical port 
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— Reception of multiple SDUs packed into a single MAC PDU is mandatory as a capability, but may 
be turned on or off on a per connection basis 

— Fragmentation of SDUs is mandatory as a capability, but may be turned on or off on a per connection 
basis 

— ARQ is mandatory as a capability, but may be turned on or off on a per connection basis 

— Handling of undecodable transmissions in an initial ranging slot 

Conditionally mandatory features: 

— If nrtPS or BE services are supported, then the SS responding to broadcast polling is mandatory 

— If multicast polling groups are supported, multicast polling must be supported 

12.2.1 .3 Conventions for MAC Management Messages for profiles prof M4 and profMS 

The following rules shall be followed when reporting parameters in MAC Management messages: 

— Service Class Names should not be used 

— DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU 
Indicator, SDU Size, ATM Switching, or Convergence Sublayer Specification TLVs 

12.2.2 WirelessMAN-SCa Power class profiles 

A power class profile contains the class(es) of BS and SS transmitters used in a system. A power class 
profile may contain transmitters from more than one class, with the profile indicating the highest power 
level class permitted. 

The power classes for BS and SS transmitters in a system are listed in Table 393. 

The power ratings, PT X ,max> associated with these classes are the maximum average output power ratings at 
which the appropriate transmitter requirements in Table 394 or Table 396 are met. 



Table 393— Power classes 



Classidentifier 


Transmit Power (dBm) 


Class 1 


17 ^ P T x,max<20 j 


Class 2 


20 < P T x,max<23 


Class 3 


23 < P T x^ax<30 


Class 4 


30<P T x,max . 
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12.2.3 WirelessMAN-SCa Physical Layer (PHY) Profiles 

This subclause specifies PHY profiles for systems using the WirelessMAN-SCa PHY. The scope includes 
both licensed and license-exempt (WirelessHUMAN) operation. 

Table 394 and Table 395 list minimum Tx and Rx performance requirements for an SS. Table 396 and Table 
397 list minimum Tx and Rx performance requirements for a BS. Elements in these tables that are not 
applicable to a particular profile (such as those governing modulations not used by a profile) may be 
disregarded. 



Table 394— SS minimum Tx performance requirements 



Capability 


Minimum performance 


RF frequency 


A frequency band (but not 
necessarily all bands) below 1 1 
GHz 


RF frequency accuracy 


±15*10"* 


Tx dynamic range 


>30 dB 


RMS power level at maximum power level setting 


>15 dBm 


Power level minimum adjustment step 


1 dB 


Power level adjustment step relative accuracy 


Monotonic,± 25% of adjustment 
step, but < 4 dB 


Power level absolute accuracy 


±6 dB 


Peak-to-peak symbol jitter, referenced to the previous symbol zero- 
crossing of the transmitted waveform, as percentage of nominal symbol 
duration when measured over period of 2 seconds 


2% 


Burst timing step size 


±0.25 of a symbol 


Burst timing step size accuracy 


±0.125 of a symbol 


Spectral mask (OOB) 


Local regulation 


Ramp up/ramp down time 


< 5 jas 


Output noise power spectral density when not transmitting 


Local regulation; < -80 dBm/Hz 
when no regulation 


Transmitter minimum SNR at antenna feed point 


40 dB 


Transition time from Tx to Rx and from Rx to Tx 


TDD: 2 \is 
H-FDD: 20 (xs 
FDD: n/a 



Table 395— SS minimum Rx performance requirements 



Capability 


Minimum performance 


Maximum on-channel input level 


-20 dBm 


Maximum on-channel input level without Rx damage 


OdBm 
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Table 395 — SS minimum Rx performance requirements (continued) 



Capability 


Minimum performance 


Transition time from Tx to Rx and from Rx to Tx 


TDD: 2 us 
H-FDD: 20 us 
FDD: n/a 


Uncoded sensitivity at BER = 10" 3 


BPSK: -96.2 + 10 log(BW in MHz) dBm 
QPSK: -93.2 + 10 Iog(BW in MHz) dBm 
16-QAM: -86.2 + 10 log(BW in MHz) dBm 
64-QAM: -80.0 + 10 log(BW in MHz) dBm 
256-QAM: -73.8 + 10 log(BW in MHz) dBm 


Transition time from Tx to Rx and from Rx to Tx 


TDD: 2 \is 
H-FDD: 20 us 
FDD: n/a 


C/I, with interferer in first adjacent channel resulting in 3 
dB degradation at BER = 10~ 3 


BPSK: < -12 dB 
QPSK: < -9 dB 
16-QAM: < -2 dB 
64-QAM: < +5 dB 
256-QAM: < +12 dB 


C/I, with interferer in first adjacent channel resulting in 1 
dB degradation at BER = 10" 3 


BPSK: < -8 dB 
QPSK: < -5 dB 
16-QAM: < +2 dB 
64-QAM: < +9 dB 
256-QAM < +16 dB 


C/I, with interferer in second adjacent channel resulting in 
3 dB degradation at BER = 10~ 3 


BPSK: < -37 dB 
QPSK: < -34 dB 
16-QAM: < -27 dB 
64-QAM: < -20 dB 
256-QAM: < -1 3 dB 


C/I, with interferer in second adjacent channel resulting in 
1 dB degradation at BER = 10~ 3 


BPSK: < -33 dB 
QPSK: < -30 dB 
16-QAM: < -22 dB 
64-QAM: <-l 6 dB 
256-QAM: < -9 dB 



Table 396 — BS minimum Tx performance requirements 



Capability 


Minimum performance 


RF frequency 


A frequency band (but not 
necessarily all bands) below 
11 GHz 


RF frequency accuracy 


±8*10^ 


Tx dynamic range 


>20 dB±3 dB 


RMS power level at maximum power level setting 


>15 dBm 


Power level minimum adjustment step 


ldB i 


Power level adjustment step relative accuracy 


Monotonic, ± 25% 
adjustment step, but < 4 dB 
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Table 396— BS minimum Tx performance requirements (continued) 



Capability 


Minimum performance 


Pnu/f»r IpvpI absolute accuracv 


±6 dB 


Peak-tn-neak svmhol iitter referenced to the previous symbol zero-crossing of 
the transmitted waveform, as percentage of nominal symbol duration when mea- 
sured over a period of 2 seconds 


2% 


Spectral mask (00B) 


Local regulation 


Spurious 


Local regulation 


Ramp up/ramp down time 


<5 u.s 


Transmitter minimum SNR at antenna feed point 


40 dB 


Modulation accuracy when measured with an ideal receiver without an equalizer 


BPSK: < 12% 
vjrolv. < IZVo 
16-QAM:<6% 
64-QAM: < 3.1 
256-QAM:<1.5% 


Transition time from Tx to Rx and from Rx to Tx 


TDD: 2>s 
H-FDD: 20 
FDD: n/a 



Table 397— BS minimum Rx performance requirements 



Capability 


Minimum performance 


Maximum on-channel input level 


-40 dBm 


Maximum on-channel input level without receiver damage 


OdBm 


Uncoded sensitivity at BER = 10" 3 


BPSK: -96.2 +101og(BW in MHz) dBm 
QPSK: -93.2 +101og(BW in MHz) dBm 
16-QAM: -86.2 +101og(BW in MHz) dBm 
64-QAM: -80.0 +101og(BW in MHz) dBm 
256-QAM: -73.8 +10 log(BW in MHz) dBm 


C/I, with interferer in first adjacent channel resulting in 3 dB 
degradation at BER - 10~ 3 


BPSK:<-12dB 
QPSK: < -9 dB 
16-QAM: < -2 dB 
64-QAM: < +5 dB 
256-QAM: < +12 dB 


C/I, with interferer in first adjacent channel resulting in 1 dB 
degradation at BER = 10" 3 


BPSK: < -8 dB 
QPSK: < -5 dB 
16-QAM: < +2 dB 
64-QAM: < +9 dB 
256-QAM: < +16 dB 


C/I, with interferer in second adjacent channel resulting in 3 
dB degradation at BER = 10" 3 


BPSK: < -37 dB 
QPSK: < -34 dB 
16-QAM: < -27 dB 
64-QAM: < -20 dB 
256-QAM: < -1 3 dB 
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Table 397— BS minimum Rx performance requirements (continued) 



Capability 


Minimum performance 


C/I, with interferer in second adjacent channel resulting in 1 


BPSK:<-33 dB 


dB degradation at BER = 10~ 3 


QPSK:<-30 dB 




16-QAM:<-22 dB 




64-QAM:<-16dB 




256-QAM:<-9 dB 



All PHY profiles shall share the common characteristics in 12.2.3.1, while individual profiles shall be 
differentiated by the specific characteristics listed in 12.2.3.2. All Baseline profiles nominally support the 
mandatory concatenated FEC, and, through the inclusion of additional descriptors, are capable of specifying 
the use of BTC or CTC FEC options. 



12.2.3.1 Common features of PHY profiles 

All PHY profiles shall share characteristics listed in the ensuing descendent clauses. 

For WirelessHUMAN operation, the channel BW shall be 10 MHz. For WirelessMAN operation, allowed 
channel bandwidths shall be limited to the regulatory provisioned bandwidth divided by any power of 2, but 
no less than 1 .25 MHz. 

12.2.3.1.1 Common Mandatory features 

The following features shall be supported by all PHY profiles: 

— Spread BPSK, QPSK, 16-QAM, 64-QAM downlink and UL 

— Roll-off Factor = 0.25 

— SymbolRate(Mbd/s) = (BWinMHz-0.088)/1.25 

— RS code word length N = 255 bytes (with exception of shortened last RS code word) 

— RS code words with R = 16 bytes 

— Downlink Preamble composed of 3 UWs and 4 ramp-up symbols 

— Uplink Preamble composed of 1-5 UWs and 4 ramp-up symbols 

— No Pilot Words 

— Block interleaver, N R - 10 

— Frame Duration 4 ms 

The following features may be supported, but when supported, must conform to the parameters specified: 

— 256-QAM downlink and uplink 

— Downlink Pilot words with length 1 UW and interval 1024 symbols 

— STC where 

Downlink preamble composed of 3 UWs per half-dual block (6 UWs total) and 4 ramp-up symbols 
Downlink STC blocks of length 1024 symbols with block burst profile "0" 
Downlink Pilot word distribution, determined by Pilot Word DCD burst profile TLV 

— Subchannel framing where 
Preamble composed of 2 UWs, 
Subchannel framing parameters {k y d} = { 1,1 }, 

r = 1024 for 16 symbol UWs and r = 4096 for 64-symbol UWs 
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12.2.3.1.2 Conventions for MAC management messages for profiles 

The following rules shall be followed when reporting parameters in MAC Management messages: 

— Roll-off Factor shall be reported in UCD message. 

— RS Information Byte and RS Parity Bytes shall be reported in UCD message. 

— Burst Set Type and STC Parameters shall be reported in UCD message. 

12.2.3.1.3 UCD and DCD parameters 

12.2.3.1.3.1 and 12.2.3.1.3.2 specify the TLV-encoded parameters which shall be transmitted in the respec- 
tive DCD and UCD messages by systems meeting a PHY profile. Systems implementing the profile shall 
only include the parameters listed under the respective message in its transmission of said messages. Param- 
eters with defined default values should be omitted if the desired value coincides with the default one. 

12.2.3.1.3.1 DCD 

— BSEIRP 

— TTG (omitted for FDD) 

— RTG (omitted for FDD) 

— Power Adj ustment Rule 

— RSSiR )inax 

— MAC version 

— Downlink Burst Profile(s) 

— Modulation Type 

— Exit Threshold 

— Entry Threshold 

— CC/CTC-specific Parameters 

— Block Interleaver Depth (omitted if Modulation Type does not specify use of a block interleaver) 

— BTC Code Selector (omitted if Modulation type does not specify use of a BTC) 

— Spreading Parameters (omitted if Modulation type does not reference a spread BPSK type) 

12.2.3.1.3.2 UCD 

— Symbol Rate (omitted for TDD) 

— Frequency (omitted for TDD) 

— SSTG 

— Power Adjustment Rule 

— Contention-based Reservation Timeout 

— Initial Ranging SSTG (if omitted, value is same as SSTG) 

— Uplink Burst Profile(s) 

— Modulation Type 

— Preamble Length 

— CC/CTC-specific Parameters 

— Unique Word Length 

— Pilot Word Parameters 

— Burst set type 

— Block Interleaver Depth (omitted if Modulation Type does not specify use of a block interleaver) 

— BTC Code Selector (omitted if Modulation type does not specify use of a BTC) 

— STC parameters (omitted if Burst set type is not STC) 

— Spreading Parameters (omitted if Modulation type does not reference a spread BPSK type) 

— Subchannel framing parameters (omitted if Burst set type does not specify subchannel usage) 
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12.2.3.2 Specific PHY profiles 

12.2.3.2.1 FDD-specific PHY profile features 

Mandatory features: 

— FDD operation 

— BS must respect half-duplex nature of half-duplex SSs 

— Center Frequency and symbol rate for uplink must be reported in UCD channel encoding 

12.2.3.2.2 TDD-specific PHY profile features 

Mandatory features: 

— TDD operation 

— Center Frequency and symbol rate for uplink are not reported in UCD channel encoding 

12.2.3.2.3 WirelessHUMAN-specific PHY profile features 

Mandatory features: 

— TDD operation 

— Center Frequency and symbol rate for uplink are not reported in UCD channel encoding 

— Channel Nr is reported in DCD channel encoding 

— UW length 1 6, 64, and 256 symbols 

— DFS capability 

Detection of primary users with received signal strength in excess of -64 dBm 
Channel switching within 300 |xs 

12.2.3.2.4 ProfP6: WirelessMAN-SCa PHY profile A 

Profile Identifier: profP6 
Mandatory features: 

— Symbol rate SR < 1.25 MBd/s 

— UW length 16 symbols 

12.2.3.2.5 ProfP7: WirelessMAN-SCa PHY profile B 

Profile Identifier: profP7 
Mandatory features: 

— Symbol rate 1.25 > SR < 20 MBd/s 

— UW length 16, 64, and 256 symbols 

12.2.3.2.6 ProfP8: WirelessMAN-SCa PHY profile C 

Profile Identifier: profP8 
Mandatory features: 

— Symbol rate SR > 20 MBd/s 

— UW length 256 symbols 
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12.2.4 WirelessMAN-SCa RF profiles 

12.2.4.1 RF profiles for 3.5 MHz channelization 

12.2.4.1.1 profRI 

Mandatory features: 

— RF channels:(Uplink for FDD) 2524.75 + n • 0.25 MHz, Vn € {0, 1, 266} 

(Downlink for FDD) 2598.75 + n - 0.25 MHz, Vn e {0, 1, 266} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.1.2 prof R2 

Mandatory features: 

— RF channels: (Uplink for FDD) 341 1.75 + n • 0.25 MHz, Vn e {0, 1, 126} 

(Downlink for FDD) 3461.75 + n ■ 0.25 MHz, Vn e {0, 1, 126} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.1.3 prof R3 

Mandatory features: 

— RF channels: (Uplink for FDD) 3501.75 + n • 0.25 MHz, Vn € {0, 1, 182} 

(Downlink for FDD) 3551.75 + n ■ 0.25 MHz, Vne {0, 1, 182} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.1.4 profR4 

Mandatory features: 

— RF channels: (Uplink for FDD) 3601.75 + n ■ 0.25 MHz, Vn e {0, 1, 182} 

(Downlink for FDD) 3651.75 + n • 0.25 MHz, Vne {0, 1, 182} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.1.5 prof R5 

Mandatory features: 

— RF channels: (Uplink for FDD) 3701.75 + n ■ 0.25 MHz, Vn e {0, 1, 182} 

(Downlink for FDD) 3751.75 + n • 0.25 MHz, Vn e {0, 1, 182} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.2 RF profiles for 7 MHz channelization 

12.2.4.2.1 profR6 

Mandatory features: 

— RF channels: (Uplink for FDD) 2526.5 + n ■ 0.25 MHz, Vn e {0, 1, 252} 

(Downlink for FDD) 2600.5 + n • 0.25 MHz, Vn e {0, 1, 252} 
Using FDD, n shall be identical for uplink and downlink. 
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12.2.4.2.2 prof R7 

Mandatory features: 

— RF channels: (Uplink for FDD) 3413.5 + «■ 0.25 MHz, V/ie {0,1,..., 112} 

(Downlink for FDD) 3463.5 + n- 0.25 MHz, Vn e {0, 1, 112} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.2.3 profR8 

Mandatory features: 

— RF channels: (Uplink for FDD) 3503.5 + n 0.25 MHz, Vn e {0, 1, 168} 

(Downlink for FDD) 3553.5 + n • 0.25 MHz, Vn e {0, 1, 168} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.2.4 profR9 

Mandatory features: 

— RF channels: (Uplink for FDD) 3603.5 + n ■ 0.25 MHz, Vn e {0, 1, 168} 

(Downlink for FDD) 3653.5 + n • 0.25 MHz, Vn e {0, 1, 168} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.2.5 profRIO 

Mandatory features: 

— RF channels: (Uplink for FDD) 3703.5 + n ■ 0.25 MHz, Vn e {0, 1, 168} 

(Downlink for FDD) 3753.5 + n • 0.25 MHz, Vn e {0, 1, 168} 
Using FDD, n shall be identical for uplink and downlink. 

12.2.4.3 RF profiles for 10 MHz channelization 

12.2.4.3.1 profR11 

Mandatory features: 

— RF channels: 5000 + n • 5 MHz, Vn e {55, 57, 59, 61, 63, 65, 67} 

— Spectral mask: See 8.6.2 

12.2.4.3.2 prof R1 2 

Mandatory features: 

— RF channels: 5000 + n ■ 5 MHz, Vn e { 148, 150, 152, 154, 156, 158, 160, 162, 164, 166} 

— Spectral mask: See 8.6.2 

12.2.4.3.3 profR13 

Mandatory features: 

— RF channels: 5000 + n • 5 MHz, Vne {147, 149, 151, 153, 155, 157, 159, 161, 163, 165, 167, 169} 

— Spectral mask: See 8.6.2 
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12.2.4.4 RF profiles for 20 MHz channelization 

12.2.4.4.1 profR14 

Mandatory features: 

— RF channels: 5000 + n ■ 5 MHz, Vn e { 56, 60, 64 } 

— Spectral mask: See 8.6.2 

12.2.4.4.2 profR15 

Mandatory features: 

— RF channels: 5000 + n • 5 MHz, Vn e { 149, 153, 157, 161, 165} 

— Spectral mask: See 8.6.2 

12.2.4.4.3 prof R1 6 

Mandatory features: 

— RF channels: 5000 + n • 5 MHz, Vn e { 148, 152, 156, 160, 164, 168} 

— Spectral mask: See 8.6.2 

12.3 WirelessMAN-OFDM and WirelessHUMAN(-OFDM) System Profiles 

This subclause defines system profiles for systems operating with the WirelessMAN-OFDM air interface 
and with the WirelessHUMAN interface where it uses the OFDM PHY. 

A system profile consists of five components: a MAC profile, a PHY profile, a RF profile, a duplexing 
selection, and a power class. The defined PHY and MAC profiles are listed in Table 398. 



Table 398— Profile definitions 



Identifier 


Description 


profM3_PMP 


WirelessMAN-OFDM Basic packet PMP MAC profile 


profM3_Mesh 


WirelessMAN-OFDM Basic packet Mesh MAC profile 


profP3_1.75 


WirelessMAN-OFDM 1.75 MHz channel basic PHY profile 


profP3_3.5 


WirelessMAN-OFDM 3.5 MHz channel basic PHY profile 


profP3_7 


WirelessMAN-OFDM 7 MHz channel basic PHY profile 


profP3_3 


WirelessMAN-OFDM 3 MHz channel basic PHY profile 


profP3_5.5 


WirelessMAN-OFDM 5.5 MHz channel basic PHY profile 


profP3_10 


WirelessHUMAN (-OFDM) 10 MHz channel basic PHY profile 
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The transmit power class profiles, as shown in Table 399, are based on the maximum mean transmit power 
^Tx. mM using all non-guard subcarriers, for which the transmitter requirements as defined in 8.3.10 are met. 



Table 399 — Power classes profiles 



Identifier 


Transmit power performance 


profC3_0 


^max<14 dBm 


profC3_14 


14<P^ max <17dBm 


profC3_17 


17</ > T x,max<20 dBm 


profC3_20 


20 < P Txsnsa < 23 dBm 


profC3_23 


^Tx.max ^ 23 dBm 



The duplexing shall be selected as follows: A system shall implement TDD and/or FDD. A FDD SS system 
may be implemented either as half -duplex or as full-duplex. A FDD BS system must respect the half-duplex 
nature of half-duplex SSs. 

Using these conventions, a sample system profile is shown in Table 400. This sample system profile may 
also be represented by a concatenation of the profile components: 

profM3_PMP.profP3_10.profR10^1.TDD.profC3_17. 

Table 400 — Sample system profile 

Sample system profile 

{ 

; profM3J>MP ' 

profP3_10 
j profR10_l 

TDD 

profC3_17 
J 

12.3.1 WirelessMAN-OFDM and WirelessHUMAN(-OFDM) MAC Profiles 

This subclause defines MAC profiles for systems operating with the WirelessMAN-OFDM air interface and 
with the WirelessHUMAN interface where it uses the OFDM PHY. 
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12:3.1.1 ProfM3_PMP: Basic Packet PMP MAC System Profile 

This profile specifies a set of capability requirements when a system is operating in the mandatory PMP 
mode. Table 401 lists the optional MAC features and designates whether they shall or may be implemented 
to comply with this profile. 



Table 401— Optional feature requirements profM3_PMP 



Optional Feature 


Required? 


Conditions/Notes 


Packet convergence sublayer 
Payload header suppression 
Ipv4 over 802.3/Ethernet 
802.3/Ethemet 


Yes 
No 
Yes 
Yes 




ATM convergence sublayer 


No 




Multicast polling groups 
Multicast polling 


Yes 




CRC functionality 


Yes 


Elective per connection. 


Unsolicited grant service functionality 


No 




Real-Time Polling services 


No 




Best effort services 


Yes 




Ma« ppnl Tim a Pnllincr cpfviff^c 

rNUii~r\.cdi- i inic x uuiug aci viwco 


Yes 




No data encryption, no data authentication and 
3-DES,l28 

CBC-Mode 56-bit DES, no data authentication 
and 3-DES,l28 

No data encryption, no data authenti cation and 
RSA, 1024 

CBC-Mode 56-bit DES, no data authentication 
and RSA, 1024 

AES, CCM mode, no data authentication and 
AES with 128-bit key 


No 
Yes 
No 
No 
No 




Undecodable initial ranging feature 


Conditional 


Required for SS. 
Not required for BS. 


ARQ 


No 




Mesh 


No 


If used, apply profM3_Mesh 


AAS 


•No 




DFS 


Conditional 


Required when intended for license 
exempt bands. 

Not required when intended for 
licensed bands. 


BS capability for support of manageable SSs 
(creating secondary management connections, 
DHCP, TFTP, SNMP etc.) 


Yes 
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— Support of IPv4 capabilities at the Packet Convergence Sublayer means capability of classification 
and IPv4 datagrams encapsulation into MAC SDUs as specified in 5.2.6. It is relevant to both DL 
andUL. 

— Support of IEEE 802.3/Ethernet capabilities at the Packet Convergence Sublayer means capability of 
classification and IEEE 802.3/Ethernet frames encapsulation into MAC SDUs as specified in 5.2.4. 
It is relevant to both DL and UL. 

— Support of ARQ is defined as the minimum capability to support eight simultaneous ARQ 
connections. 

— Support of CRC means ability to add CRC at Tx and ability to check CRC at Rx in the case when 
CRC presence is signaled by CI. 

12.3.1.1.1 Conventions for MAC Management Messages 

The following rules shall be followed when reporting parameters in MAC Management messages: 

— Service Class Names should not be used. 

— DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU 
Indicator, SDU Size, ATM Switching, or Convergence Sublayer Specification TLVs. 

12.3.1.1.2 MAC Management Message Parameter Transmission Order 

TLVs within MAC Management messages shall be ordered as follows. Parameters for optional features shall 
occur after those listed for support of mandatory features. Features that are defined as optional, but are 
mandated by the implemented Profile, if any, shall be ordered as optional. Both mandatory and optional 
TLVs shall subsequently be sequenced in order of increasing Type value. Parameters with defined default 
values should be omitted if the desired value coincides with the default one. 
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12.3.1.2 ProfM3_Mesh: Basic Packet Mesh MAC System Profile 

This profile specifies a set of capability requirements when a mesh enabled system is operating in the 
optional mesh mode. Table 402 lists the optional MAC features and designates whether they shall or. may be 
implemented to comply with this profile. 



Table 402— Optional feature requirements profM3_mesh 



Optional Feature 


Required? 


Conditions/Notes 


Packet convergence sublayer 
Payload header suppression 
Ipv4 

802.3/Ethernet 


Yes 
No 
Yes 
Yes 




ATM convergence sublayer 


No 




Provisioned connections 


No 




Classification of packets on incoming physical port 


No 




Multicast polling groups 
Multicast polling 


N/A 




CRC functionality 


Yes 




Dynamic services 


Yes 




Unsolicited grant service functionality 


N/A 




Real-Time Polling services 


N/A 




Best effort services 


Yes 




Non-Real-Time Polling services 


N/A 




Cryptographic suites: 
No data encryption, no data authentication and 
3-DES,128 

CBC-Mode 56-bit DES, no data authentication 
ana j-Dfco,izo 

No data encryption, no data authentication and 
RSA, 1024 

CBC-Mode 56-bit DES, no data authentication 
and RSA, 1024 

AES, CCM mode, no data authentication and 
AES with 128-bit key 


No 
No 
No 
Yes 
No 




Undecodable initial ranging feature 


N/A 




ARQ 


Yes 




AAS 


No 




DFS 


Conditional 


Required when intended for license 
exempt bands. 

Not required when intended for 
licensed bands. 



— Support of ARQ functionality is mandatory as a capability, but may be turned on or off on a per 
packet basis. ARQ shall be used when the reliability bit in the Mesh CID is set to 1, and shall not be 
used otherwise. ARQ parameters shall be set to: 
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ARQ Window Size = 64 DEC 

ARQ Retry Timeout = [2 - T F ~] DEC , with 7> the PHY dependent frame duration in ^s. 
ARQ Block Lifetime = \T F /2"\ DEC , with 7> the PHY dependent frame duration in jis. 
ARQ RX Purge Time Timeout = [2 • 7>~| DEC , with 7> the PHY dependent frame duration in jis. 
ARQ Sync Loss Timeout = 0 
ARQ Deliver in Order = 0 

12.3.1.2.1 MAC Management message applicability 

For a mesh-enabled system, the messages below and the corresponding functionality are always mandatory 
to implement: 

MSH-NCFG 

MSH-NENT 

MSH-DSCH 

MSH-CSCH 

MSH-CSCF 

REG-REQ 

REG-RSP 

PKM-REQ 

PKM-RSP 

SBC-REQ 

SBC-RSP 

TFTP-CPLT 

TFTP-RSP 

RES-CMD 

For a mesh enabled system, the following messages and the corresponding functionality are mandatory/ 
optional whenever they are correspondingly optional/mandatory for a PMP system: 

ARQ-Feedback 

When operating in the mesh mode, the messages below and the corresponding functionality are not used 
(they are, however, implemented to support the mandatory PMP mode). 

DL-MAP 
DCD 

DSA-ACK 

DSA-REQ 

DSA-RSP 

DSC-ACK 

DSC-REQ 

DSC-RSP 

DSD-RSP 

DSX-RVD 

UCD 

UL-MAP 

CLK-CMP 

DBPC-REQ 

DBPC-RSP 

DREG-CMD 

MCA-REQ 

MCA-RSP 
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RNG-REQ 
RNG-RSP 

Generally, the following procedures are different for a mesh node and a PMP node: 

Synchronization 
t Network entry 
Scheduling 
Power control 
Ranging 

12.3.1.2.2 MAC Management Message Parameter Transmission Order 

TLVs within MAC Management messages shall be ordered as follows. Parameters for optional features shall 
occur after those listed for support of mandatory features. Features that are defined as optional, but are 
mandated by the implemented Profile, if any, shall be ordered as optional. Both mandatory and optional 
TLVs shall subsequently be sequenced in order of increasing Type value. Parameters with defined default 
values should be omitted if the desired value coincides with the default one. 

12.3.2 WirelessMAN-OFDM and WirelessHUMAN(-OFDM) Physical Layer Profiles 

This subclause defines PHY profiles for systems operating with the WirelessMAN-OFDM and 
WirelessHUMAN(-OFDM) air interface. 

The following set of parameters are common to all defined PHY profiles and shall be complied with in order 
to comply with each individual profile. 

Table 403 lists the optional PHY features and designates whether they shall or may be implemented. 



Table 403— Optional PHY feature requirements 



Optional feature 


Required? 


Conditions/Notes 


64-QAM 


Yes 


Required for license bands, but not 
required for license-exempt bands. 


BTC 


No 




CTC 


No 




subchannelization 


No 




STC 


No 




Focused contention BW requesting 


No 




TJT b 


Conditional 


BS shall be capable of using at least 
one value. 

SS shall be capable of using entire set. 
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Table 404 lists minimum performance basic requirements for all defined profiles. 



Table 404 — Minimum Performance basic requirements 



Capability 


Minimum performance 


Tx Dynamic range 
SS 

SS (if subchannel ization supported) 
BS 


> 30 dB 

> 50 dB 

> 10 dB 


Tx Power Level minimum adjustment step 


< 1 dB 


Tx Power Level minimum relative step accuracy 


< ± 50% of step size, 
but not more than 4dB 


Tx Spectral flatness 

Absolute difference between adjacent subcarriers: 
Deviation of average energy in each subcarrier 
from the measured energy averaged over 
all 200 active tones: 

Subcarriers -50 to -1 and +1 to +50: 
Subcarriers -100 to -50 and +50 to +100: 


< 0.1 dB 

< ±2dB 

< +2/-4HR 


Soectral mask fOOB'l 


I r>fa1 rpoiilation 


Tx relative constellation error* 
BPSK-1/2 
QPSK-1/2 
QPSK-3/4 
16-QAM-1/2 
16-QAM-3/4 
64-QAM-2/3 
64-QAM-3/4 


< -13.0 dB 

< -16.0 dB 

< -18.5 dB 

< -21.5 dB 

< -25.0 dB 

< -28.5 dB 

< -31.0 dB 


Rx max. input level on-channel reception tolerance 


> -30 dBm 


Rx max. input level on-channel damage tolerance 


> OdBm 


1 st adiacent channel reiection at BER=1 0 - ^ for 3 dB 
degradation C/I 

16QAM-3/4 

64QAM-3/4 


> 11 dB 

> 4dB 


2 nd adjacent channel rejection at BER=10" j6 for 3 dB 
degradation C/I 

16QAM-3/4 

64QAM-3/4 


> 30 dB 

> 23 dB 


SSTTG and SSRTG: 
TDD and H-FDD 


< 100 


Reference frequency tolerance 
BS 

Mesh system 


< ±8*10" 6 

< ±20*10" 6 
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12.3.2.1 ProfP3_1.75: WirelessMAN-OFDM PHY profile for 1.75MHz channelization 

Mandatory features: 

— Licensed band usage only 

— Channel bandwidth BW = 1.75 MHz 

— BS shall select Frame duration from code set PMP:{2,4,6}. SSs shall be capable of operating with 
any of the Frame Durations indicated in the code set. 

Systems implementing profP3_1.75 shall meet the minimum performance requirements listed in Table 405. 



Table 405 — Minimum Performance requirements for profP3_1.75 



Capability 


Minimum performance 


n 


= 128 (is 


BER performance threshold, BER= KT 6 
BPSK-1/2 
QPSK-1/2 
QPSK-3/4 , 
16QAM-1/2 
16QAM-3/4 
64QAM-2/3 
64QAM-3/4 

Threshold change if subchannelization used 


< -94 dBm 

< -91 dBm 

< -89 dBm 

< -84 dBm 

< -82 dBm 

< -77 dBm 

< -76 dBm 

\0\og(N subchannels /16) 


Reference frequency tolerance 

SS to BS synchronization tolerance 


156.25 Hz 


Reference time tolerance 


±(7y32)/2 



12.3.2.2 ProfP3_3.5: WirelessMAN-OFDM PHY profile for 3.5 MHz channelization 

Mandatory features: 

— Licensed band usage only 

— Channel bandwidth BW = 3.5 MHz 

— BS shall select Frame duration from code set PMP:{ 2,4,6}, Mesh:{l}. SSs shall be capable of 
operating with any of the Frame Durations indicated in the code set. 
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Systems implementing profP3_3.5 shall meet the minimum performance requirements listed in Table 406: 



Table 406 — Minimum Performance requirements for profP3_3.5 



Capability 


Minimum performance 


T. 


— 64 us 


BER performance threshold, BER=10" 6 
BPS K- 1/2 

V^r olx- VIZ, 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 

64QAM-3/4 

Threshold change if subchannelization used 


< -91 dBm 
-oo oditi 

< -86 dBm 

< -81 dBm 

< -79 dBm 

< -74 dBm 

< -73 dBm 

lO\og(N subchanneb /\6) 


Reference frequency tolerance 

SS to BS synchronization tolerance 
Mesh to Mesh synchronization tolerance 


< 312.5 Hz 

< 468.75 Hz 


Reference time tolerance 


± ( V32)/2 



12.3.2.3 ProfP3_7: WirelessMAN-OFDM PHY profile for 7 MHz channelization 

Mandatory features: 

— Licensed band usage only 

— Channel bandwidth BW=lMHz 

— BS shall select Frame duration from code set PMP:{ 2,4,6}, Mesh:{l}. SSs shall be capable of 
operating with any of the Frame Durations indicated in the code set. 
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Systems implementing profP3_7 shall meet the minimum performance requirements listed in Table 407: 



Table 407— Minimum Performance requirements for profP3J7 



Capability 


Minimum performance 


T 


— 1 1 ^ 


BER performance threshold, BER=10" 6 
BPSK-1/2 

ADC IS 1 /O 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 

64QAM-3/4 

Threshold change if subchannelization used 


< -88 dBm 

S Of JD — 

< -83 dBm 

< -78 dBm 

< -76 dBm 

< -71 dBm 

< -70 dBm 

lO.\og(N subchannels /\6) 


Reference frequency tolerance 

SS to BS synchronization tolerance 
Mesh to Mesh synchronization tolerance 


<625 Hz 
< 937.5 Hz 


Reference time tolerance 


±(7y32)/2 



12.3.2.4 ProfP3_3: WirelessMAN-OFDM PHY profile for 3 MHz channelization 

Mandatory features: 

— Licensed band usage only 

— Channel bandwidth BW = 3.0 MHz 

— BS shall select Frame duration from code set PMP:{ 2,4,6}, Mesh:{4}. SSs shall be capable of 
operating with any of the Frame Durations indicated in the code set. 
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Systems implementing profP3 J3 shall meet the minimum performance requirements listed in Table 409: 



Table 408 — Minimum Performance requirements for profP3_3 



Capability 


Minimum performance 


T, 
l b 


- 73 99 us 
" 73 437^ S 


BER performance threshold, BER=10~ 6 
BPSK-1/2 

QPSK-3/4 

16-QAM-I/2 

16-QAM-3/4 

64-QAM-2/3 

64-QAM-3/4 

Threshold change if subchannelization used 


< -91 dBm 
s — oo at>m 

< -87 dBm 

< -81 dBm 

< -80 dBm 

< -75 dBm 

< -73 dBm 

10!og(^ cAaii;ie/ /16) 


Reference frequency tolerance 

SS to BS synchronization tolerance 
Mesh to Mesh synchronization tolerance 


< 273.13 Hz 

< 409.67 Hz 


Reference time tolerance 


± (r^/32)/2 



12.3.2.5 ProfP3_5.5: WirelessMAN-OFDM PHY profile for 5.5 MHz channelization 

Mandatory features: 

— Licensed band usage only 

— Channel bandwidth BW = 5.5 MHz 

— BS shall select Frame duration from code set PMP:{ 2,4,6}, Mesh: {4}. SSs shall be capable of 
operating with any of the Frame Durations indicated in the code set. 
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Systems implementing profP3_5.5 shall meet the minimum performance requirements listed in Table 409: 



Table 409— Minimum Performance requirements for profP3_5.5 



Capability 


Minimum performance 


T b 


~dn 120 ,.< 
- 4 °l57^ S 


BER performance threshold, BER=10" j6 
BPSK-1/2 
QPSK-1/2 
QPSK-3/4 
16-QAM-1/2 
16-QAM-3/4 
64-QAM-2/3 
64-QAM-3/4 

Threshold change if subchannelization used 


< -89 dBm 

< —oo dbm 

< -84 dBm 

< -79 dBm 

< -77 dBm 

< -72 dBm 

< -71 dBm 

\0\og{N subchannels /\6) 


Reference frequency tolerance 

SS to BS synchronization tolerance 
Mesh to Mesh synchronization tolerance 


< 490.63 Hz 

< 735.94 Hz 


Reference time tolerance 





12.3.2.6 profP3_10: WirelessHUMAN(-OFDM) PHY profile for 10 MHz channelization 

Mandatory features: 

— License-exempt band usage only 

— Channel bandwidth BW = 10 MHz 

— TDD operation 

— BS shall select Frame duration from code set PMP:{ 2,4,6}, Mesh:{l}. SSs shall be capable of 
operating with any of the Frame Durations indicated in the code set. 

— DFS capability 

— Ability to detect primary users with received signal strength in excess of -67 dBm 

— Ability to switch channel within 300 us 
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Systems implementing profP3_10 shall meet the minimum performance requirements listed in Table 410: 



Table 410 — Minimum Performance requirements for profP3_10 



Capability 


Minimum performance 


Tb 




Spectral mask (IB): 

f 0 ±0MHz 
f 0 ±4.75 MHz 
f 0 ±5.45 MHz 
f 0 ±9.75 MHz 
iq x /j iviriz 


Linear interpolation 

between points: 

OdBr 

OdBr 

-25 dBr 

-32 dBr 

— ju at>r 


BER performance threshold, BER=10 -6 
BPSK-1/2 

V^iiJiV- It £. 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 

64QAM-3/4 

Threshold change if subchannelization used 


< -86dBm 

< 8^ HRm 
. — Uijiri 

< -81 dBm 

< -76 dBm 

< -74 dBm 

< -69 dBm 

< -68 dBm 

\0\og(N 5ubchannels /\6) 


Reference frequency tolerance 

SS to BS synchronization tolerance 
Mesh to Mesh synchronization tolerance 


< 892.5 Hz 

< 1339 Hz 


Reference time tolerance 


±(V32)/2 



12.3.3 WirelessMAN-OFDM RF profiles 

For licensed bands, no explicit RF profiles are defined. A compliant system shall adhere to the requirements 
of 8.3.10.2 for the specified supported bands. 

12.3.3.1 RF profiles for 10 MHz channelization 

12.3.3.1.1 ProfR10_1 

Mandatory features: 

— RF channels: : 5000 + n • 5 MHz, Vn € {55, 57, 59, 61, 63, 65, 67 } 

— Spectral mask: See 8.5.2 

12.3.3.1.2 prof R10_2 

Mandatory features: 

— RF channels: : 5000 + n • 5 MHz, V* e { 148, 150, 152, 154, 156, 158, 160, 162, 164, 166} 

— Spectral mask: See 8.5.2 
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12.3.3.1.3 profR10_3 

Mandatory features: 

— RF channels: :5000 + n ■ 5 MHz, Vne {147, 149, 151, 153, 155, 157, 159, 161, 163, 165, 167} 

— Spectral mask: See 8.5.2 

12.4 WirelessMAN-OFDMA and WirelessHUMAN(-OFDMA) system profiles 

This subclause defines system profiles for systems operating with the WirelessMAN-OFDMA and 
WirelessHUMAN-OFDMA air interfaces. 

Any feature not mandatory or conditionally mandatory for a profile is optional for the profile except where 
otherwise forbidden by the standard. Optional features shall be implemented as specified in the standard. 



Table 411 — Profile definitions 



Identifier 


Description 


OFDMA.profMl 


WirelessMAN-OFDMA basic packet PMP MAC Profile 


OFDMA.profPl 


WirelessMAN-OFDMA 1.25 MHz channel basic PHY Profile 


OFDMA_profP2 


WirelessMAN-OFDMA 3.5 MHz channel basic PHY Profile 


OFDMA_profP3 


WirelessMAN-OFDMA 7 MHz channel basic PHY Profile 


OFDMA_profP4 


WirelessMAN-OFDMA 14 MHz channel basic PHY Profile j 


OFDMA_profP5 


WirelessMAN-OFDMA 28 MHz channel basic PHY Profile 


OFDMA_profP6 


WirelessHUMAN(-OFDMA) 10 MHz channel basic PHY Profile 


OFDMA_profP7 


WirelessHUMAN(-OFDMA) 20 MHz channel basic PHY Profile 



12.4.1 WirelessMAN-OFDMA Power class profiles 

A power class profile contains the class(es) of BS and SS transmitters used in a system. A power class 
profile may contain transmitters from more than one class, with the profile indicating the highest power 
level class permitted 

the power classes for BS and SS transmitters in a system are listed in Table 412. 

The power ratings, Pj Xymax , associated with these classes are the maximum average output power ratings at 
which the appropriate transmitter requirements in 8.4.12 are met. 



766 



Copyright © 2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS IEEE Std 802.16-2004 



Table 412 — Power classes 



Class identifier 


Transmit power (dBm) 


Class 1 


17 < P T x,max<20 


Class 2 


20 < P T x,max<23 


Class 3 


23 < P T x,max<30 


Class 4 


3° ^ P Tx,max 



12.4.2 WirelessMAN-OFDMA and WirelessHUMAN(-OFDMA) MAC Profiles 

This subclause defines MAC profiles for systems operating with the WirelessMAN-OFDMA and 
WirelessHUMAN-OFDMA air interfaces. 

12.4.2.1 Basic Packet PMP MAC Profile 

Profile identifier: OFDM A_ProfM 1 . 
Mandatory Features: 

— Support of Packet convergence sublayer. 

— Support of Internet Protocol Ipv4. 

— Support IEEE 802.3/Ethernet specific part. 

— CRC functionality shall be supported for all connections. 

— Support of dynamic services. 

— Support of Best effort services. 

— Support of Non-Real-Time Polling services. 

— Support of CDMA based Initial and Periodic Ranging. 

— Support of Contention based CDMA bandwidth requests. 

— DFS shall be required for the license exempt bands only. 

12.4.2.1.1 Conventions for MAC Management Messages 

The following rules shall be followed when reporting parameters in MAC Management messages: 

*■ 

— Service Class Names should not be used. 

— No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSA-RSP and DSC- 
RSP messages. 

— No TLVs besides HMAC Tuples shall be reported back in DSA-ACK messages. 

— DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU 
Indicator, SDU Size, ATM Switching, or Convergence Sublayer Specification TLVs. 

12.4.2.1.2 MAC Management Message Parameter Transmission Order 

Systems implementing the profile OFDM AJProfM 1 shall transmit the TLV encoded parameters for 
mandatory features in the respective messages. Those systems only include the parameters listed under the 
respective message in its transmission of these messages plus any parameters necessary for optional 
features. Parameters for optional features shall occur after those listed for support of mandatory features. For 
the required features, the relevant parameters shall be transmitted in order of increasing Type value of the 
parameter's TLV key. Parameters with defined default values should be omitted if the desired value 
coincides with the default one. 
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12.4.3 WirelessMAN-OFDMA and WirelessHUMAN(-OFDMA) System PHY Profiles 

This subclause defines PHY profiles for systems operating with the WirelessMAN-OFDMA air interface 
and WirelessHUMAN-OFDMA air interfaces. 

12.4.3.1 Common Features of PHY Profiles 

All PHY profile shall share the common characteristics as defined in Table 413 while individual profiles 
shall be differentiated by the specific characteristics listed for each profile. 

If one of the PHY profiles has a parameter, which is different from the parameter defined by the common 
parameters section, then the values stated in the PHY profile override the value stated in the common 
parameters section. 

12.4.3.1.1 General implementation requirements 

The following optional features are not required for implementation of any PHY profiles: 

— BTC 

— CTC 

— 64-QAM 

— STC 

The following features must be supported by all PHY profiles: 
Guard Time 

BS shall be capable of using at least one allowed value. 

SS shall be capable of detecting and using entire set of allowed values 

Frame Duration 

SSs shall be capable of operating with any of the Frame Durations as defined at 8.4.5.2. 

12.4.3.1.2 FDD-Specific PHY Profiles Features 

Mandatory features: 

— FDD Operation 

— BS must respect half-duplex nature of half duplex SS 

— Center Frequency for uplink must be reported in the UCD channel encoding 

12.4.3.1.3 TDD-Specific PHY Profiles Features 

Mandatory features: 

— TDD Operation 

— Center Frequency for uplink is not reported in the UCD channel encoding 

12.4.3.1.4 WirelessHUMAN PHY Profiles Features 

Mandatory features: 

— TDD Operation 
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— Ability to detect primary users with received signal strength in excess of -61 dBm 

— Center Frequency for uplink is not reported in the UCD channel encoding. 

— Channel Nr is reported in DCD channel encoding 

— Ability to switch channel within 300 \is 

12.4.3.1.5 Minimum performance requirements 

Table 413 lists the minimum performance requirements needed for all profiles. 



Table 413— Minimum performance requirements for all profiles 



Capability 


Minimum performance 


Tx Dynamic range 
SS 
BS 


> 30 dB 

> 10 dB 


Tx Power Level minimum adjustment step 


< 1 db 


Tx Power Level minimum relative step accuracy 


< ±0.5dB 


BS Spectral flatness, when using all subchannels. 
Absolute difference between adjacent subcarriers: 
(2.5dB should be added for Pilot carriers within the 
symbol due to their boosting). 


< 0.1 dB 


Deviation of average energy in each carrier 
from the measured energy averaged over 
all 1702 active tones: 

Carriers -425 to -1 and +1 to +425: 


< ±2dB 


Carriers -85 1 to -425 and +425 to +85 1 : 


< +2/-4dB 


SS Spectral flatness, when using all subchannels. 
Absolute difference between adjacent subcarriers: 
(2.5 dB should be added for Pilot carriers within the 
symbol due to their boosting). 


< 0.1 dB 


Deviation of average energy in each carrier 
from the measured energy averaged over 
all 1696 active tones: 

Carriers -424 to -1 and +1 to +424: 


< ±2dB 


Carriers -848 to -424 and +424 to +848: 


< +2/-4dB 


Spectral mask (OOB) 


Local regulation 


Tx relative constellation error: 
QPSK-1/2 
QPSK-3/4 
16-QAM-1/2 
16-QAM-3/4 

64-Q AM-2/3 (if 64-QAM supported) 
64-QAM-3/4 (if 64-QAM supported) 


< -19.4 dB 

< -21.2 dB 

< -26.4 dB 

< -28.2 dB 

< -32.7 dB 

< -34.4 dB 


Rx max. input level on-channel reception tolerance 


> -30 dBm 


Rx max. input level on-channel damage tolerance 


> OdBm 
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Table 413— Minimum performance requirements for all profiles (continued) 



Capability 


Minimum performance 


Miimiw Of ^nhrhannpK Snnnnrted when receiving/ 
transmitting 

SS 

BS 


1-32 
1-32 


1 s * jiHinrpnt rhannel reiection at BER=10~~^ for 3 dB 
degradation C/I 
16-QAM-3/4 

64-QAM-3/4 (if 64-QAM supported) 


> 11 dB 

> 4dB 


2 nd adjacent channel rejection at BER=1(T 6 for 3 dB 
degradation C/I 
16-QAM-3/4 

64-QAM-3/4 (if 64-QAM supported) 


> 30 dB 

> 23 dB 


SSTTG and SSRTG: 
TDD 
H-FDD 


< 50 |xs 

< 100 \i s 


Reference time tolerance 


± (T b /32)/10 



12.4.3.2 WirelessMAN-OFDMA 1.25 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfPl. 

Systems implementing OFDMA_ProfPl shall meet the minimum performance requirements listed i 
Table 414: 



Table 414— Minimum performance requirements for OFDMA_ProfP1 



Capability 


Minimum performance 


Channel bandwidth 


1.25 MHz 


Operation mode 


Licensed bands only 


Tx Dynamic range 
SS 
BS 


> 40 dB 

> 10 dB 


Tx relative constellation error: 
QPSK-1/2 
16-QAM-3/4 


< -22.4 dB 

< -28.2 dB 


1 st adjacent channel rejection at BER=10" 6 for 3 
dB degradation C/I 
16-QAM-3/4 


> 30dB 


2 nd adjacent channel rejection at BER=10~* for 3 
dB degradation C/I 
16-QAM-3/4 


> 80 dB 
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(continued) 



Capability 


Minimum performance 


BER performance threshold, BERslO" 6 (using all 
subchannels BS/SS) 

QPSK-1/2 

16-QAM-3/4 


<-90 dBm 
<-80 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 

DC 
DO 

SS to BS synchronization tolerance 


✓-.1*1 r\—6 
S ± 1*1U 

<2Hz 


TTG (TDD only) 


>200 u.s 


RTG (TDD only) 


>5 us 


Frame duration code set 


{4,7} 



12.4.3.3 WirelessMAN-OFDMA 3.5 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP2. 

Systems implementing OFDMA_ProfP2 shall meet the minimum performance requirements listed in Table 
415: 



Table 415— Minimum Performance requirements for OFDMA_ProfP2 



Capability 


Minimum performance 


Channel bandwidth 


3.5 MHz 


Operation mode 


Licensed bands only 


BER performance threshold, BER=10"^ (using all 
subchannels BS/SS) 

QPSK-1/2 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 (if 64-QAM supported) 
64QAM-3/4 (if 64-QAM supported) 


< -87 dBm 
<-84 dBm 

< -80 dBm 
<-77 dBm 
<-73 dBm 
<-71 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChanneIsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10* 6 
<20 Hz 


Frame duration code set 


{4,7} 
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12.4.3.4 WirelessMAN-OFDMA 7 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP3. 

Systems" implementing OFDMA_ProfP3 shall meet the minimum performance requirements listed in 
Table 416: 



Table 416— Minimum Performance requirements for OFDMA_ProfP3 



Caoahilitv 


Minimum performance 


Channel bandwidth 


7 MHz 


Operation mode 


i_>icenscu uaiius uiuy 


BER performance threshold BER=10~^ fusing all 
subchannels BS/SS) 
. QPSK-1/2 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 (if 64-QAM supported) 
64QAM-3/4 (if 64-QAM supported) 


< -84 dBm 
<-81 dBm 
< -77 dBm 

< -74 dBm 

< -71 dBm 

< -68 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10-* 
<40 Hz 


Frame duration code set 


{2,3,5} 
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12.4.3.5 WirelessMAN-OFDMA 8.75 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP4. 

Systems implementing OFDMA_ProfP4 shall meet the minimum performance requirements listed in Table 
417: 



Table 417— Minimum Performance requirements for OFDMA_ProfP4 



Capability 


Minimum performance 


Channel bandwidth 


8.75 MHz 


Operation mode 


Licensed bands only 


BER Derformance threshold BER=10~^ (usinp all 
subchannels BS/SS) 

QPSK-1/2 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 (if 64-QAM supported) 
64QAM-3/4 (if 64-QAM supported) 


< -82.5 dBm 

< -79.5 dBm 

< -75.5 dBm 
<-72.5 dBm 

< -68.5 dBm 

< -66.6 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChanneIsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10" 6 
<48 Hz 


Frame duration code set 


{2, 4, 6,8} 


Spectrum mask 


Local regulation 



NOTE— When using this profile, the sampling frequency (see 8.4.2.4) shall be: F s = floor(nxBW/2000)x2000 
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12.4.3.6 WirelessMAN-OFDMA 14 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP5. 

Systems implementing OFDMA_ProfP4 shall meet the minimum performance requirements listed in 
Table 418: 



Table 41 a— Minimum Performance requirements for OFDMA_ProfP5 



Capability 


Minimum performance. 


Channel bandwidth 


14 MHz 


WpCiaiivJii niuut/ 


Licensed bands only 


BER performance threshold, BER=10~^ (using all 
subchannels BS/SS) 

QPSK-1/2 

QPSK-3/4 

16-QAM-1/2 

16-QAM-3/4 

64-QAM-2/3 (if 64-QAM supported) 
64-QAM-3/4 (if 64-QAM supported) 


<-81 dBm . 
<-78 dBm 

< -74 dBm 
<-71 dBm 

< -67 dBm 
<-65 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10~* 
<80 Hz 


Frame duration code set 


{2,3,5} 
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12.4.3.7 WirelessMAN-OFDMA 17.5 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP6. 

Systems implementing OFDMA_ProfP6 shall meet the minimum performance requirements listed in 
Table 419: 



Table 419 — Minimum Performance requirements for OFDMA_ProfP6 



Capability 


Minimum performance 


Channel bandwidth 


17.5 MHz 


Operation mode 


Licensed bands only 


BER oerformance threshold BER=10~^ fusine all 

J-JiJ*X UV11VI lllUJIvv LIU vOJl V/JUj UIjIV™" 1 \J ^UOlllk till 

subchannels BS/SS) 
QPSK-1/2 
QPSK-3/4 
16-QAM-1/2 
16-QAM-3/4 

64-QAM-2/3 (if 64-QAM supported) 
64-QAM-3/4 (if 64-QAM supported) 


< -79.5 dBm 
< -76.5 dBm 

< -72.5 dBm 

< -69.5 dBm 
< -65.5 dBm 
$-63.6 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10^ 
<97 Hz 


Frame duration code set 


{2,4, 6,8} 


Spectrum mask 


Local regulation 



NOTE— When using this profile, the sampling frequency (see 8.4.2.4) shall be: F s = floor(nxflWZ2000)x2000 



Copyright ©2004 IEEE. All rights reserved. 



775 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



12.4.3.8 WirelessMAN-OFDMA 28 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP7. 

Systems implementing OFDMA_ProfP7 shall meet the minimum performance requirements listed in Table 
420: 



Table 420 — Minimum Performance requirements for OFDMA_ProfP7 



Capability 


Minimum performance 


Channel bandwidth 


28 MHz 


wpeiaiion mouc 




BER performance threshold, BER=10~ 6 (using all 
subchannels BS/SS) 

QPSK-1/2 

QPSK-3/4 

16-QAM-1/2 
1 16QAM-3/4 

64QAM-2/3 (if 64-QAM supported) 

64QAM-3/4 (if 64-QAM supported) 


<-78 dBm 
< -75 dBm 
< -71 dBm 
< -68 dBm 
< -64 dBm 
<-62 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10 -6 
< 160Hz 


Frame duration code set 


{2,3,5} 
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12.4.3.9 WirelessHUMAN(-OFDMA) 10 MHz channel basic PHY Profile 

Profile identifier: OFDMAJ>rofP8. 



Systems implementing OFDMA_ProfP8 shall meet the minimum performance requirements listed in 
Table 421: 



Table 421— Minimum Performance requirements for OFDMA_ProfP8 



Capability 


Minimum performance 


Channel bandwidth 


10 MHz 


Operation mode 


Licensed-exempt band 
usage only 


BER performance threshold, BER=10~ 6 (using all 
subchannels BS/SS) 

QPSK-1/2 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 (if 64-QAM supported) 
64QAM-3/4 (if 64-QAM supported) 


< -82 dBm 
<-79 dBm 
<-75 dBm 

< -72 dBm 

< -68 dBm 
<-66 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*10~ 6 
<55 Hz 


Frame duration code set 


{2,4,5} 
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12.4.3.10 WirelessHUMAN(-OFDMA) 20 MHz channel basic PHY Profile 

Profile identifier: OFDMA_ProfP9. 

Systems implementing OFDMAJ > rofP9 shall meet the minimum performance requirements listed in Table 
422: 



Table 422— Minimum Performance requirements for OFDMA_ProfP9 



Capability 


Minimum performance 


Channel bandwidth 


20 MHz 


Operation mode 


Licensed-exempt band 
usage only ! 


BER performance threshold, BER=10~^ (using all 
subchannels BS/SS) 

QPSK-1/2 

QPSK-3/4 

16QAM-1/2 

16QAM-3/4 

64QAM-2/3 (if 64-QAM supported) 
64QAM-3/4 (if 64-QAM supported) 


<-79 dBm 
<-76 dBm 
<-72 dBm 
<-69 dBm 
<-65 dBm 
<~63 dBm 


[Add to sensitivity 10*logl0(NumberOfSub- 
ChannelsUsed/32) when using less subchannels 
in the BS Rx] 




Reference frequency tolerance 
BS 

SS to BS synchronization tolerance 


<±4*HT 6 
< 110 Hz 


Frame duration code set 


{2,4,5} 



12.4.4 WirelessMAN-OFDMA RF profiles 

This subclause defined RF profiles for the WirelessMAN-OFDMA and WirelessHUMAN(-OFDMA) air 
interfaces. 

Table 423 defines the RF channels for the license bands, the channels shall be calculated using the following 
formula: F start + n • AF C , \/n e N range 

where: 

F start is the start frequency for the specific band, 

AF C is the center frequency step, 

Grange * s me range values for the n parameter. 



778 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 

Table 423 — License bands RF Profiles List 



IEEE Std 802.16-2004 



RF profile name 


Channel 
bandwidth 


Center 
frequency 
step AF C 


Uplink F start 


Downlink 

'start 


■ * rnn op 


OFDMA_ProfRl 


1.25 


1.25 


2150.625 


N/A 


{0,1,..,7} 


OFDMA_ProfR2 


1.25 


1.25 


2305.625 


N/A 


{0.1 12} 


OFDMA_ProfR3 


1.25 


1.25 


2345.625 


N/A 


(13,14,...,24) 


OFDMA__ProfR4 


1.25 


1.25 


2500.625 


N/A 


{0,1,...,150} 


OFDMA_ProfR5 


1.25 


1.25 


3400.625 


N/A 


{0,1,...,240) | 


OFDMA_ProfR6 


3.5 


1.75 


2524.75 


2598.75 


{0,1,...,38} 


OFDMA_ProfR7 


3.5 


1.75 


3411.75 


3461.75 


{0.1.....18} 


OFDMA_ProfR8 


3.5 


1.75 


3501.75 < 


3551.75 


{0,1,..,55} 


OFDMA_ProfR9 


3.5 


1.75 


3601.75 


3651.75 


{0,1,. ..,55) 


OFDM A_ProfR 1 0 


3.5 


1.75 


3701.75 


3751.75 


{0,1,...,55} 


OFDM A_ProfR 1 1 


7 


1.75 


2526.5 


2600.5 


{0,1,...,36} 


OFDM A_ProfR 1 2 


7 


1.75 


3413.5 


3463.5 


{0.1 16} 


OFDM A_ProfR 1 3 


7 


1.75 


3503.5 


3553.5 


{0,1,.. .,53} 


OFDMA_ProfR14 


7 


1.75 


3603.5 


3653.5 


{0,1,...,53} 


OFDMA_ProfR15 


7 


1.75 


3703.5 


3753.5 


{0,1,...,53} 


OFDMA_ProfR16 


14 


1.75 


2530 


2604 


{0,1,...,32} 


OFDM A_ProfR 1 7 


14 


1.75 


3417 


3467 


{0,1,...,12} 


OFDM A_ProfR 1 8 


14 


1.75 


3507 


3550 


{0,1,.. .,49} 


OFDM A_ProfR 1 9 


14 


1.75 


3607 


3650 


{0,1,.. .,49} 


OFDM A_ProfR20 


14 


1.75 


3707 


3750 


{0,1,. ..,49} 


OFDM A_ProfR2 1 


28 


1.75 


2537 


2611 


{0,1,...,24} 


OFDMA_ProfR22 


28 


1.75 


3424 


3467 


{0,1,...,4} 


OFDMA_ProfR23 


28 


1.75 


3514 


3557 


{0,1, ...,41} 



Copyright © 2004 IEEE. All rights reserved. 



779 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS — PART 16: 

Table 423— License bands RF Profiles List (continued) 



RF profile name 


Channel 
bandwidth 


Center 
frequency 
step AF C 


Uplink F start 


Downlink 

F start 


N 

" range 


OFDM A_ProfR24 


28 


1.75 


3614 


3657 


{0,1,...,41} 


OFDMA_ProfR25 


28 


1.75 


3714 


3757 


{0,1,...,41} 


OFDMA_ProflR26 


10 


5 


5000 


N/A 


{55,57,59,61,63, 
65,67} 


OFDMA_ProfR27 


10 


5 


5000 


N/A 


{148, 150, 152, 
154, 156, 158, 
160, 162, 164, 


OFDMA_ProfR28 


10 


5 


5000 


N/A 


{147, 149, 151, 
1 SS 1^7 

159, 161, 163, 
165, 167, 169} 


OFDMA_ProfR26 


20 


5 


5000 


N/A 


{56,60,64} {149, 

Ijj, I J / , lOl, 

165} 


OFDMA_ProfR27 


20 


5 


5000 


N/A 


{149, 153, 157, 
161, 165} 


OFDMA_ProfR28 


20 


5 


5000 


N/A 


{148, 152, 156, 
160, 164, 168} 


OFDMA_ProfR29 


8.75 


0.125 


2304.375 


N/A 


{0,...,730} j 


OFDMA_ProfR30 


17.5 


0.125 


2308.75 


N/A 


{0,...,660} 



NOTES: 

l_For 10,20 MHz channels, a spectral mask as defined in 8.6.2 should be applied. 
2 — For FDD and H-FDD cases, both uplink and downlink shall have the same n value. 
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Annex B 

(informative) 

Supporting material for frequencies below 11 GHz 



B.1 Targeted frequency bands 

Table B.1 indicates frequency bands, and their allowed channel spacings, where WirelessMAN-SCa, 
WirelessMAN-OFDM or WirelessMAN-OFDMA may be applicable. 



Table B.1— Frequency bands and channel allocation 



Frequency bands (GHz) 
(licensed unless noted) 


Allowed channel spacing 


Reference 


2.305-2.320 
2.345-2.360 


1 or 2 x (5 + 5 MHz) or 1 x 5 MHz 
(Can be aggregated in any combina- 
tions) Interference Protection to digi- 
tal audio radio satellite (DARS) 


USA CFR 47 part 27 (WCS) See FCC 
Docket IB95-91 for potential (increased) 
interference from DARS repeaters. 


2.150-2.162 
2.500-2.690 


125 kHZto(nx6) MHz 
Single or multiple, contiguous or non- 
contiguous and combinations. 
Interference Protection to video and 
ITFS users 


USA CFR 47 part 21.901 (MDS) 
USA CFR 47 part 74.902 [ITFS, 
multichannel multipoint distribution 
service (MMDS)] 


2.150-2.160 
2.500-2.596 
2.686-2.688 


1 MHz - (n x 6) MHz (1 or 2-way) 
25 kHz - (n x 25 kHz) "return" 
Contiguous channels preferred 


Canada SRSP-302.5 (MCS) 
MDS service allocated to adjacent 
sub-bands (incl. separate "return" 
channels) 


2.400-2.483.5 
(license -exempt) 


Frequency Hopping or Direct 
Sequence Spread Spectrum etc. 


CEPT/ERC/REC 70-03 

USA CFR 47 Part 15, subpart E [B19] 


3.400-4.990 


3.410-4.200 


1.75-30 MHz paired with 
1.75-30 MHz 
Symmetric only. 

(50 MHz or 100 MHz separation) 


Rec. ITU-R F1488 Annex II 
ETSI EN 301 021[B15], 
CEPT/ERC Rec. 14-03 E, CEFT/ERC 
Rec. 12-08 E 




3.400-3.700 


n x 25 MHz (single or paired) 
(50 MHz or 100 MHz separation if 
paired) 


Rec. ITU-R F.1488 Annex I 
CITEL PCC.III/REC.47 (XII-99) 
Canada SRSP-303.4 (BWA) 




3.650-3.700 


Rulemaking in progress 


USA FCC Docket WT00-32 




4.940-4.990 


Rulemaking in progress 


USA FCC Dockets WTOO-32 and 
ET-98-237 
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Table B.1— Frequency bands and channel allocation (continued) 



Frequency bands (GHz) 
(licensed unless noted) 


A llnu/fwl rlionn^l cnanno 
/viiu Wcu niaiiiici spacing 


Reference 


5.150-5.850 
(license- 
exempt) 


5.150-5.350 


n x 20 MHz (HIPERLAN) 
Restricted to Indoor Use 


CEF17ERC/REC 70-03 


5.470-5.725 


n x 20 MHz (HIPERLAN) 


5.250-5.350 


100 MHz maximum 
Restricted to Indoor Use 


USA CFR 47 Part 15, subpart E [B19] 
USA CFR 47 Part 15, subpart C [B19] 


5.250-5.350 


100 MHz maximum 


5.725 -5.850 


125 MHz maximum 


10.000-10.680 


3.5-28 MHz paired with 
3.5-28 MHz. Symmetric only 
350 MHz separation 


CEPT/ERC/REC. 12-05 
ETSI EN 301 021 [B15] 



B.2 License-exempt co-existence and interference analyses 
B.2.1 Interference mitigation and sharing mechanisms 

A number of license-exempt interference mitigation and sharing mechanisms are identified. Two categories 
are considered — mechanisms that fall within the scope of this standard and methods that fall outside that 
scope. 

Within the scope of this standard, two methods are identified: DFS and transmit power control, both are 
mandated in this document (see 6.3.15 and 8.3.7.4, respectively) as well as by some regulatory regions 
(ERC/DEC/(99)23, [B10]). 

Two methods outside the scope of this standard are identified — antenna directivity and antenna polarization. 
B.2.1. 1 DFS 

As frequency planning is not practical in licensed-exempt bands, DFS can be used to avoid assigning a 
channel to a channel occupied by another system. DFS is generally based on comparison of a C/I threshold 
against idle time RSSI measurements. DFS is predominantly effective to combat interference from and to 
ground-based systems, such as RLANS, RTTT, radar and other WirelessHUMAN-compliant systems. It is 
generally ineffective to combat interference from and to airborne systems, such as airborne radars and 
satellites. 

B.2.1. 2 Transmit power control 

With power control, the transmitter EIRP is reduced according to the link margin. Shorter link ranges result 
in lower transmitted power levels. For PMP systems, the average EIRP will typically be several decibels 
below the legal limit assuming that SSs are spread throughout the coverage area. For Mesh systems, this 
means that EIRP values decrease rapidly as customer deployment density increases. As power control is also 
influenced by C/I levels, the use of adaptive power control with DFS, where possible, tends to result in the 
most effective interference mitigation. 
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B.2.1.3 Antenna directivity 

Antenna directivity, in horizontal but especially in vertical direction, can significantly reduce a BWA 
system's interference potential and resilience. Vertical directivity especially reduces the interference caused 
to satellite systems, which are designated primary users of part of the addressed bands. It also can 
significantly help reduce interference to and from indoor RLAN systems. Horizontal directivity significantly 
reduces the probability of interference to other systems (assuming interference is mainly caused in the main 
lobe), but tends to increase the severity of the interference, as the energy in the main lobe is generally higher. 

B.2.1.4 Antenna polarization 

Antenna cross-polarization in the 5-GHz band can achieve an isolation of up to 15 dB in LOS, but reduces 
significantly in near-LOS and NLOS environments. Most deployments use both horizontal and vertical 
polarization (circular polarization is not as common in currently known systems) to maximize spectral reuse. 
Polarization hence has the potential to provide some isolation between differently polarized systems, 
especially in LOS, but given the operational needs and implementation of most systems in the targeted 
spectrum, the effectiveness will be mostly marginal. 

B.2.2 Services in the 5 GHz band 

To enable co-existence studies, a short description of the systems and services in the 5-GHz bands is 
provided together with the necessary parameters for the subsequent interference analysis. This includes 
assumptions on parameters of WirelessHUMAN-compliant systems that are beyond the scope of this 
standard. 

B.2.2. 1 WirelessHUMAN PMP system 

PMP are based upon the use of a central BS with distributed SSs. 

Parameters shown in Table B.2 for sample BWA systems BWA1 and BWA2 are assumed. 

Table B.2— Single U-NII BWA to synthetic aperture radar 4 (SAR-4) Interference 



Parameter 


BWAj 


BWA 2 


units 


Transmitted power (antenna port) 


0 


dBW 


Antenna high elevation gain 


0 


-4 


dB 


Building loss (dB) 


0 


dB 


Polarization 


H/V 


H/V 





B.2.2.2 WirelessHUMAN Mesh system 

The Mesh deployment scenario is abstracted into a regular hexagonal shape as shown in Figure B.l. On each 
corner of each hexagon, one Mesh node is located. By parameterizing the distance between a set of 
neighboring nodes, different Mesh deployment density scenarios can relatively easily be analyzed. 

If the distance between two nodes is denoted r, then from each node, there are 3 neighbors at distance r, 6 
nodes at distance 2ri 3 fl\ 3 nodes at distance 2r; 6 nodes at distance 3ri 3 /2; 6 nodes at distance 3r\ 12 
nodes at distance -4 A 3/2; 3 nodes at distance 4r\ 12 nodes at distance ~5rV 3 /2 etc. 
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Figure B.1— WirelessHUMAN Mesh deployment model 



Mesh devices that are close to each other cannot transmit at the same time on the same channel. This is 
normally defined in terms of extended neighborhoods, which comprises all nodes within two hops from the 
transmitting node. For modeling purposes, it is assumed that if a node is transmitting, all other nodes on the 
three hexagons that intersect on that node are silent. This translates into all nodes within a distance of 2r 
being silent. 

In Table B.3, the topology and traffic assumptions are shown. The Tx activity of a node depends heavily on 
its position in the network, i.e., the amount of traffic that has to be forwarded from or to other nodes; and the 
activity of neighboring nodes. To keep the analysis simple, an average of 5% is assumed (This is based on 
the current average household internet usage of 30 minutes per day, as well as the activity probability during 
this on-time). 



Table B.3— Tx activity parameters 



Parameter 


Value 


Typical hops/packet 


2 


Total Tx activity 


5% 



Based on this model, the background interference at any node can be computed, which can be added to the 
interference from the node in question, resulting in the overall system interference. 

B.2.2.2.1 Antenna parameters 

The Mesh device is assumed to be using omni-directional antennas at all times, which is a worst-case 
assumption, as nonbroadcast communications between nodes could be performed with multiple antennas to 
reduce overall interference. 
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It is extremely important to notice that the Mesh device is by necessity a roof-mounted device, as it has to 
extend coverage in all directions. In contrast to PMP SSs, which are typically installed under the eaves, the 
amount of vertical scattering, which is harmful to both ground-based RLAN devices and satellites, is 
significantly less despite the lack of horizontal directivity. This is due to the relatively good probability of 
clear LOS of the nodes to each other due to their individual mounting location as well as the significantly 
shorter distances to each other than a PMP SS typically enjoys to its BS. 

For these reasons, no extra scattering in the vertical direction is assumed for this evaluation besides the 
antenna pattern. 

As shown in Table B.4, the antenna is an 8 dBi gain omni-directional antenna with a -22 dBi vertical gain 
and worst-case -15 dBi between 30° and 50° from vertical. 



Table B.4— Antenna parameters 



Parameter 


Value 


Mounting 


Outdoors/rooftop 


Gain 

(Horizontal omni-directional) 


8dBi@ 90° 

-22 dBi @ 0-30° 
-15 dBi @ 30-50° 


Polarization 


Vertical 



B.2.2.2.2 Radio parameters 

Although 10 MHz channelization is also defined, the focus here is on the mandatory 20 MHz channelization, 
. which gives the worst-case scenarios. 

It is important to note that, throughout this study, the use of 6 dBW maximum EIRP is assumed for all parts 
of the spectrum with a backoff of only 3 dB for RLAN type devices. It should be understood that this study 
errs on the side of caution when considering the amount of interference that can be tolerated; as an example, 
in a practical OFDM system, the backoff is in the order of at least 6 dB minimum, whereas the rules 
commonly specify at most 0 dBW maximum mean EIRP (ERC/DEC/(99)23 [B10]) or 6 dBW maximum 
peak EIRP (FCC CFR Title 47 [B19]) for fractions of the band. The relevant assumed ratio parameters are 
shown in Table B.5. 



Table B.5 — Relevant radio parameters 



Parameter 


Value 


Transmit power 


28 dBm 

(i.e., 36 dBm maximum EIRP) 
with dynamic power control 


20 dB bandwidth 


21 MHz 


Peak-to- Average power ratio 


3dB 
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The Rx sensitivity and C/I parameters are obtained from Equation (98) (NF = 7 dB, margin = 5 dB). 

For the purpose of analytical full network interference analysis, the receiver sensitivity of the Mesh system is 
chosen to be -75 dBm, an average of the modulation and coding mode sensitivities up to rate 1/2, 16-QAM, 
which will be the most likely used in practical deployments. 

B.2.2.3 Earth exploratory satellite system (EESS) and fixed satellite service (FSS) 

Two types of satellite services are deployed in the 5 GHz — FSS and EESS services. EESS services are 
provided by two distinct types of satellite — Altimeter satellites and SAR satellites. 

B.2.2.3.1 Altimeter satellites 

The characteristics of altimeter satellites, as shown in Table B.6, have been derived from ERC Report 72 
[B12]. 

Table B.6 — Altimeter satellite characteristics 



Parameter 


Value 


Bandwidth 


320 MHz 


Rx sensitivity 


-88 dBm 


On-axis antenna gain 


32.5 dBi j 


Off-axis antenna gain 


10 3 - 25 (Sin(<p)/<p) 2 . a 


Antenna size 


1.2 m 


Height 


1344 km 


Input loss = Output loss 


ldB 


Coverage 


q> e [-60°, 60°] 


Bandwidth 


320 MHz 



<p is the angle between the vertical and the direction of the ground-based 
device. 



B.2.2.3.2 SAR satellites 

The characteristics of SAR-1 through SAR-4 satellites, as shown in Table B/7, have been derived from ERC 
Report 72 [B12]. 

Table B.7— Typical space borne imaging radar characteristics 



Parameter 


Value 


SARI 


SAR2 


SAR3 


SAR4 


Orbital altitude 


426 km (circular) 


600 km (circular) 


400 km (circular) 


400 km (circular) 


Orbital inclination 


57° 


57° 


57° 


57° 


RF Centre frequency 


5305 MHz 


5305 MHz 


5305 MHz 


5300 MHz 
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Table B.7— Typical space borne imaging radar characteristics (continued) 



Parameter 


Value 


SARI 


SAR2 


SAR3 


SAR4 


Peak radiated power 


4.8 Watts 


4800 Watts 


1700 Watts 


1700 Watts 


Polarization 


Horizontal 
(HH) 


Horizontal and Ver- 
tical 

(HH,HV,VH,VV) 


Horizontal and Ver- 
tical 

(HH,HV,VH,VV) 


Horizontal and 
Vertical 

(HH,HV,VH,VV) 


Pulse modulation 


Linear FM chirp 


Linear FM chirp 


Linear FM chirp 


Linear FM chirp 


Pulse bandwidth 


8.5 MHz 


310 MHz 


310 MHz 


40 MHz 


Pulse duration 


100 |is 


31 |ls 


33 (is 


33 |is 


Pulse repetition rate 


650 pps 


4492 pps 


1395 pps 


1395 pps 


Duty cycle 


O.D fO 


l J. 7 /0 


j.y /o 


5.9% 


Range compression 
ratio 


850 


9610 


10230 


1320 


Antenna type 


Planar phased 
array 

0.5 mx 16.0 m 


Planar phased array 
1.8 mx 3.8m 


Planar phased array 
0.7 m x 12.0 m 


Planar phased array 
0.7mxl2.0m 


Antenna peak gain 


42.2 dBi 


42.9 dBi 


42.7/38 dBi 
(full focus/beam- 
spoiling) 


42.7/38 dBi 
(full focus/beam- 
spoiling) 


Antenna median 
sidelobe gain 


-5 dBi 


-5 dBi 


-5 dBi 


-5 dBi 


Antenna orientation 


30° from nadir 


zu— Jo from nadir 


ZO—dd rrom nadir 


20—55 Irom nadir 


Antenna half-power 
beamwidth | 


8.5° (El), 
0.25° (Az) 


1.7° (El), 
0.78° (Az) 


4.9/18.0° (El), 
0.25° (Az) 


4.9/18.0° (El), 
0.25° (Az) 


Antenna polarization 


Linear horizontal/ 
vertical 


Linear horizontal/ 
vertical 


Linear horizontal/ 
vertical 


Linear horizontal/ 
vertical 


System noise 
temperature 


550 K 


550 K 


550 K 


550 K 


Image swath width 


50 km 


20 km 


16 km/ 320 km [ 


16 km/ 320 km 



For both the S AR imaging missions and the topographic missions, a minimum SNR is defined, below which 
the radar image pixels, and/or differential phase measurements are unacceptably degraded. Studies suggest 
that: 

— The degradation of the normalized standard deviation of power received from a pixel should be less 
than 10% in the presence of interference; 

— The aggregate interference power-to-noise power ratio (corresponding to a pixel SNR of 0 dB) 
should be less than -6 dB; 

— These levels may be exceeded upon consideration of the interference mitigation effect of SAR 
processing discrimination and the modulation characteristics of the radiolocation/ radio-navigation 
systems operating in the band; 
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— The maximum allowable interference level should not be exceeded for more than 1% of the images 
in the sensor service area for systematic occurrences of interference and should not be exceeded for 
more than 5% of the images in the sensor service area for random occurrences of interference. 

The data loss criteria have been fully utilized to achieve sharing with the radio determination service. This 
study therefore uses the degradation interference criteria to derive the sharing constraints on BWA devices. 
Assuming that the interfering signal distribution is white Gaussian noise, the maximum acceptable 
interference signal is indicated in Table B.8. 



Table B.8— Typical space borne imaging radar characteristics 



Parameter 


Value 


Noise (dBW) 


-129.5 


-113.8 


-113.8 


-122.7 


Min. desired signal (dBW) 


-189.7 


-198.6 


-187.1 


-187.0 


IVldA. at/CCJJUHJlC 

interfering signal (dBW) 


-135.5 


-119.8 


-119.8 


-128.7 


Receiver bandwidth (MHz) . 


9.8 


356.5 


356.5 


46 


Max. acceptable 
interfering spectral power 
density (dBW/Hz) 


-205.4 


-205.4 


-205.4 


-205.4 


Antenna polarization 


Linear horizontal/ 
vertical 


Linear horizontal/ 
vertical 


Linear horizontal/ 
vertical 


Linear horizontal/ 
vertical 


System noise 
temperature 


550 K 


550 K 


550 K 


550 K 


Receiver front end 1 dB 
compression point ref to 
receiver input 


-62 dBW input 


-62 dBW input 


-62 dBW input 


-62 dBW input 


Ground illumination area 


93 km (elevation), 
2.2 km (azimuth) 


At 20° from nadir: 
20 km (elevation), 
8.7 km (azimuth) 


At 20° from nadir: 
40 km (elevation) 
2 km (azimuth) 


At 20° from nadir: 
40 km (elevation) 
2 km (azimuth) 



B.2.2.3.3 FSS satellites 

The characteristics of FSS satellites have been derived from ERC Report 72 [B12]. 

The maximum allowable interference power spectral density tolerated by FSS satellites is given by 

p = -42 + (G/T) -y dBW/Hz (155) 

where G is the gain of the satellite antenna, T the noise temperature (G/T is termed the merit factor), and y 
the link gain. FSS satellites are geo-stationary and located at 36 000 km, resulting in 199 dB pathloss. In the 
case of the Telecom 3 network (ERC Report 72 [B12]), which is used as an example, y is 0 dB, the total link 
equivalent noise temperature is 870 K, the gain for the "Metropole" spot is 34 dBi and the coverage area of 
this spot is all of Europe. G/T then becomes 4.6 dB. 
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B.2.2.4 RLANs 

The RLAN deployments considered here are the ETSI BRAN HIPERLAN/2 [B17] and IEEE 802.11a 
devices. Only indoor deployments are considered in detail. It is clear that outdoor RLAN devices cannot 
generally co-exist in the same channel with BWA devices in the same geographical area. However, the use 
of DFS, as well as the fact that the hotspot locations envisioned for outdoor RLAN deployments (such as 
airports and school campuses) do not generally coincide with the residential areas Mesh devices are targeted 
towards, easily resolve this type of RLAN deployments. The relevant RLAN assumptions are shown in 
Table B.9 and Table B. 10. 



Table B.9— RLAN Parameters I 



Parameter 


Value i 


Antenna type 


Isotropical 


Tx probability RLAN device 


5% 


Tx power 


30 dBm maximum EIRP with • 
dynamic power control 


Radio access 


TDD/TDMA 



Table B.10— RLAN parameters ll a 



Modulation 


Coding rate 


Rx sensitivity 
(dBm @ 10% PER) 


C/I 

(dB @ 10% PER) 


BPSK 


1/2 


-82 


6 


3/4 


-81 


11 


QPSK 


1/2 


-79 


9 


3/4 


-77 


14 


16-QAM 


1/2 


-74 


16 


3/4 


-70 


20 


64-QAM 


1/2 


-66 


25 


3/4 


-65 


30 



a Copied from IEEE Std 802.11a™-1999 [B29], Table 91. 
B.2.2.5 Road transport and traffic telematics (RTTT) 

Road transport and traffic telematics (RTTT) devices (ETSI EN 300 674 [B14]) are allocated in the band 
5795-5805 MHz (2 x 5 or 1 x 10), with an extension band 5805-5815 MHz (2 x 5 or 1 x 10), which may be 
used on a national basis at multi-lane road junctions. These devices are split into the Road Side Unit (RSU) 
and the onboard unit (OBU), the parameters for which are shown in Table B.ll and Table B.12. 
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Table B.11— RTTT RSU parameters 



Parameter 


Value 


Tx power (maximum EIRP) 


3dBW 


Rx sensitivity 


-105 to -130 dBW a 


Antenna gain 


20 dB 


C7I:2/4/8-PSK 


6/9/12dB 


Polarization 


circular 



a This range is merely informative. The device shall 
merely meet the manufacturer's claim. 



Table B.1 2— RTTT OBU Parameters (-35° to +35°) 



Parameter 


Value 


Class 


A,B,C,D 


E 


Re-radiated carrier power (maximum EIRP) 


-54 dBW 


-44 dBW 


Antenna gain 


IdB 


Rx sensitivity 


-73 dBW 


-70 dBW 


C/I:2/4/8-PSK 


6/9/12 dB 


C/L2/4/8-PSK 


Polarization 


Circular 


Polarization 



In analyzing the compatibility between WirelessHUMAN systems and RTTT the basic approach taken is to 
use the Minimum Coupling Loss (MCL) technique to determine the necessary separation distances between 
the two systems. 

Minimum coupling loss: L = / > f -max|l0log(^),o|-/^ (156) 

where 

is the transmitter power, 
is the receiver bandwidth (MHz), 
is the interferer bandwidth (MHz), 
is the tolerable interference at receiver (dBW). 

Required separation distance: d = ^ X (f athlossm where pathloss = L + Antenna and feeder gains and losses. 



B Rx 

Bi 



Rx 
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B.2.2.6 Radar 

The radar parameters used in the radar analysis are taken from and ERC Report 15 [Bll] and ERC Report 
72 [B12]. In the analysis, the MCL technique described in B.2.2.5 will be used, with the exception that for 
the airborne radar (radar type B), a propagation exponent 2.0 instead of 2.3 is used. 



Table B.1 3— Relevant radar parameters 



Parameter 


Value 


Radar type 


A 


B 


C 


D 


E 


Peak EIRP (dBW) 


98.6 


26 


60 


93 


97 


Bandwidth radar (MHz) 


3 


15 


30 


14 


3 


Antenna gain (dBi) 


40 


■ 0 


46 


43 


43 


Tuning range (GHz) 


5.30-5.60 


5.70-5.80 


5.40-5.82 


5.25-5.85 


5.60-5.65 


Use 


Transportable 
long range 


Airborne 


Fixed long 
range 


Transportable 
multi-function 


Fixed 
long range 



B.2.3 WirelessHUMAN PMP interference analyses 
B.2.3.1 Coexistence with SAR satellites in middle UNII 

SAR-4 is used because the SAR-4 system is more interference sensitive than SAR-3, and the SAR-4 center 
frequency is 5.3 GHz. The SAR-4 scans a path from 20° to 55° from Nadir. This corresponds to Earth inci- 
dent angles of 21° and 60°, which can be translated to angles of 69° and 30° with respect to the horizon. That 
is, any radiation from U-NII devices within that angular range could cause/contribute to satellite 
interference. 

An approach that can be used in analyzing the interference potential from Middle U-NII BWA systems into 
space-borne SAR-4 receiver is to determine the worst-case signal power received from a single BWA 
transmitter at the space borne SAR. Then, the single interferer margin can be calculated by comparing the 
single BWA interferer level with the SAR-4 interference threshold. Knowing the SAR-4 footprint, the 
allowable density of active BWA transmitters can then be calculated, if a positive margin, as calculated from 
Table B.14, results from a single BWA interferer. 



Table B.14— Single U-NII BWA to SAR-4 interference 



Parameter 


BWAj 


BWA 2 


Units 


Tx Power 


0 


dBW 


Building loss 


0 


dB 


Interference gain due to SS antenna directivity [B45] 


-6 


dB 


Antenna high elevation gain 


0 


-A 


dB 


Pathloss (425.67 km) 


-160.3 


dB 


Polarization gain (V/H -> H/V) 




-3 


dB 
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Table B.1 4— Single U-NII BWA to SAR-4 interference (continued) 



Parameter 


BWAi 


BWA 2 


Units 


Noise figure 


-4.62 


dB 


Noise power (46 MHz Rx bandwidth) 


-122.73 


dB 


SAR-4 Interference threshold (I/N=-6dB) 


128.71 


dB 


Margin (dB) 


-4.71 


-0.71 


dB 



Note that real-world antennas do not exhibit unity gain at high elevation look angles, and this feature can be 
used to mitigate interference. 

A conclusion that can be drawn is that antenna directivity, if properly utilized, will provide interference 
margin for multiple transmitters. However, it should be noted that the satellite footprint is large (53 sq. km at 
20° from Nadir and 208 sq. km at 55° from Nadir). Therefore, given the potential variables associated with 
the design, installation and maintenance of the various unlicensed transmitters, antenna directivity alone 
may not be sufficient to assure non-interference. 

The margin calculation in Table B.14 includes 3 dB polarization loss. The fact that most PMP systems rely 
on polarization for maximizing channelization, as many as half of the U-NII transmitters in a given area 
could be transmitting on each polarization. If so, the 3 dB polarization loss may not be fully realizable. 

If the satellite were restricted to one linear polarization and the U-NII transmitters were restricted to the 
other linear polarization, greater polarization isolation could be achieved. Given the operational needs of 1 
both services, this is unlikely to happen. 

B.2.4 WirelessHUMAN Mesh interference analyses 
B.2.4.1 Interference to EESS and FSS 
B.2.4. 1.1 Altimeter satellites 

The interference from one Mesh node into the boresight of the SAR can be described by Equation (157)(see 
ERC Report 72 [B12]). 

P r = P " G -°*? L (157) 

where P m G m = 6 dBm (28 dBm Output power -22 dBi top lobe) is the EIRP of the Mesh antenna in the 
vertical direction, G a = 32.5 dBi the gain of the altimeter antenna, X = 5.66 cm the wavelength, L = -1 dB 
the input loss of the altimeter, and R = 1344 km the lowest orbit. 

From this a value for P r = -132 dBm can be obtained. 

The altimeter interference threshold is -88 dBm; thus, it can be deduced that the altimeter can withstand the 
operation of huge numbers of Mesh devices simultaneously, since there is a 44 dB margin. Furthermore, the 
altimeter is built to provide measurements mainly over oceans and is not able to provide accurate data when 
a significant amount of land is in view of its antenna beam. From this analysis, it is clear that the altimeter 
will not suffer from the operation of Mesh networks; however, for completeness, the number of Mesh 
devices per square kilometer tolerable by the altimeter can be calculated. 
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The distance between the satellite and a Mesh node under angle q> is R tan((p) km. Only freespace 
attenuation, which ignores atmospheric properties (which further attenuate the signal, especially when 
<p»0) has been considered. 

For simplicity, the three Mesh nodes that on average exist in one hexagon, are assumed to be in the centre 
point of the hexagon. The hexagon grid then reduces to a square grid with 3 nodes every 2 times the distance 
of a single set of nodes. 

The value for P r is then obtained as follows: 



where r x and r 2 enumerate over the square grid, and A is the activity factor. 

This derivation is easily computed numerically. According to Digest of environmental Statistics [B44], 
significantly less than 15% s of land is used for residential areas and normally a significant fraction of the 
footprint covers water as well. Hence a Residential fraction of 0.05 is introduced, to simulate clusters of 
nodes spread out over the whole satellite footprint. The receiver sensitivity is, as discussed in B. 2.2.2.2, 
chosen to be -75 dBm. 



s Number includes land used for urban and other purposes, e.g., transport and recreation, and nonagricultural, semi-natural environ- 
ments, e.g., sand dunes, grouse moors and non agricultural grasslands, and inland waters. 
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%Satellite specifications 




Ga = 32.5; 


% dBi Antenna gain 


lambda = 0.0566; 


% m Wavelength 


L = -l; 


% dB Insertion Loss 


R= 1344; 


% km Height 


Intjimit = 88; 


%.dBm Interference limit 


%Mesh specifications 




Rbase = 0.5; 


% km Distance between two Mesh nodes 


AntGain = 8 


% dBi Mesh antenna gain (max) 


AntTop = -22 


% dBi Mesh antenna gain (top-lobe) 


RxSens =-105 


% dBW Rx sensitivity Mesh 


Pout = 28; 


% dBm Max. output power Mesh 


Backoff =3; 


% dB Average Backoff 


Activity =0.05; 




pi = 3.1415; 




pathloss = -20*logl0(3E8/(4*pi*5.3E9))+2.3*10*logl0(Rbase*1000); 


PmGm = (pathloss - AntGain + FadingMargin + RxSens) + (AntTop- AntGain) -Backoff + 30; % 


dBm 




Residential = 0.15; 


% fraction residential landuse 


Prl = 0;nodes =0; 




for rl = Rbase : Rbase/sqrt(Residential): R*sqrt(3)/2 


for r2 = Rbase : Rbase/sqrt(Residential): R*sqrt(3)/2 


if( sqrt(rl *rl+r2*r2) < R*sqrt(3)/2) 


nodes = nodes+3; 




phi = atan( 2*sqrt(r 1 *rl +r2*r2)/R ); 


Prl = Prl + sinc(2*phi/pi)*sinc(2*phi/pi); 


end; 




end; 




end; 





Figure B.2 — Mesh interference code sample 



The result of the simulation, as shown in Figure B.2, is that over 30 million nodes can be supported under 
the footprint, with 6 dB in interference margin. In many cases, shorter distances between the nodes will 
result in lower used power due to power control. Hence, in practice many more nodes could be supported 
without violating the interference limit. 

B.2.4.1.2SAR satellites 

In analogy with ERC Report 72 [B12], only the case for SAR-1 satellites is examined, since this provides the 
worst-case analysis. However, contrary to this report, it will show that, using Mesh technology, an increase 
in network density actually reduces the interference into the SAR satellite, since the dynamic power-control 
reduces the power for shorter links. The receiver sensitivity is, as discussed in B.2.2.2.2, chosen to be -75 
dBm. 

As can be seen from Table B.15, a Mesh network has limitations both on the maximum distance and 
maximum density of the network. The maximum distance that can be achieved by the Mesh network using 
4 W EIRP is about 1 km, which retains a margin of 10 dB to the interference threshold. 
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Deployments with distances between nodes of one km are however exceedingly sparse and not practical 
except in the very early stages of service rollout (i.e., when seeding the service area). 

Reducing the distance increases the number of nodes, but reduces the necessary power levels, hence reduc- 
ing the overall interference into the satellite. Increasing the density, and hence the number of nodes to very 
high levels, up to about one device per 92 m would still obtain tolerable interference levels. Deployment 
densities of this nature, especially in the areas of major interest to the satellite community (oceanic and 
agrarian), are extremely unlikely. 

To allow an easier comparison with the RLAN results in ERC Report 72 [B12], Table B.15 computes the 
number of Mesh devices that can be situated in the SAR footprint without exceeding the interference limit. 



Table B.15— Wireless HUMAN Mesh devices in the SAR footprint 



Parameter 


Value 


INOUC QlSLallCc 


1 


0.5 


0.25 


0.1 


km 


Tx antenna gain 


8 


dBi 


Rx sensitivity 


-105 


dBW 


pain 10SS 


115.93 


109.00 


10.08 


92.93 


dB 


* out required ^ciKr ) 


2.93 


^.00 


-10.92 


-20.07 


dBW 


P out required (conducted) 


-5.07 


-12.00 


-18.92 


-28.07 


dBW 


Freespace distance 


-160.8 


dB 


Building attenuation 


0 


dB 


Tx antenna gain (top lobe) 


-22 


dBi 


Polarization loss 


-3 


dB 


Peak-to- Average ratio 


-3 


dB 


Rx antenna gain (main lobe) 


42.4 


dBi 


Rx Power 


-224.90 


-231.82 


-238.74 


-247.90 


dBW/Hz 


SAR threshold 


-205 


dBW/Hz 


Margin 


19.54 


26.46 


33.38 


42.54 


dB/Hz 


SAR footprint 


22.59 


dB 


Tx activity 


-13.01 


dB 


Permissible density /km 2 /ch 


9.91 


498.78 


240.22 


1976.39 


nodes 


Nodes within SAR footprint (CEFT region) 


26967 


132804 


654001 


5380723 


nodes 



In Table B.15, it is assumed that all Mesh devices are located in the boresight of the SAR satellite, which 
provides the worst-case scenario. 

B.2.4.1.3 FSS satellites 

The bandwidth of the Mesh device is 21 MHz (73.2 dBHz). The maximum allowable interference power 
spectral density tolerated by the Telecom 3 network (see B.2.2.3.3) then becomes 27 dBW/Hz. 
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Appendix S8 of the ITU Radio Regulations [B32] gives the method to calculate the maximum interference 
power produced by an earth station to a satellite receiver. When calculating the maximum interference 
power from Mesh devices into a satellite receiver, consider all the Mesh devices under the satellite footprint 
as a single source. This means that the source is not specifically located, and only the direct top lobe of the 
Mesh antenna is taken into account. 



Table B.1 6— Tolerable Mesh nodes for FSS operation 



Parameter 


Value 


Tx EIRP 


-6 


0 


3 


6 


dBW 


Tx antenna gain (main lobe) 


8 


dBi 


Tx antenna gain (top lobe) 


-22 


dBi 


Peak- to- Average Ratio 


3 


dB 


Shielding effect 


0 


dB 


Acceptable interference 


27 


dBW 


Active users 


1000 


251 


126 


63 


nodes (thousands) 


Average Tx ratio 


5 


% 


Tolerable nodes 


300 


75.4 


37.8 


18.9 


nodes (millions) 



From Table B.16, it shows that by using 4 W (6 dBW) EIRP, an enormous amount of Mesh nodes can be in 
operation within the FSS footprint. 

B.2.4.2 Interference to RLANs 

B.2.4.2.1 Immediate neighborhood analysis 

B.2.4.2.1.1 "Same building" analysis (1) 

In the immediate neighborhood scenario, the interference from a Mesh node to a RLAN device in the same 
building is analyzed (link 1 in Figure B.3). 




Figure B.3 — Immediate neighborhood scenario 
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It is assumed for this scenario, that the distance between the Mesh node and the RLAN device in the same 
building is 5 m. The structural isolation plus attenuation due to multipath/scattering is assumed to be 25 dB 
over that distance, based to Annex 2 of ERC Report 72 [B12]. Note that this is not the same as the average 
13.4 dB assumed in ERC Report 72 [B12], since only placement of Mesh devices on the roof are considered, 
and not placement outside in general as in the outside RLAN case. This is likely to be a very modest value 
for a typical (European) home with concrete ceiling and stone tile roofing. The total attenuation is then 25 + 
20*loglO(4*K*d*fo/c) = 86 dB. Given the radiation pattern of a Mesh node transmitting at full 28 dBm (i.e., 
36 dBm EIRP), the interference level at the RLAN = 28-22-86= -80 dBm. Taking into account the backoff, 
3 dB, and the effect of the Mesh activity factor, an additional 13 dB, brings the average interference level, 
-97 dBm, far below receiver sensitivity values. Operation of a Mesh device on the roof, while running an 
RLAN network inside is hence feasible, even in the same channel. 

In this scenario, to operate the RLAN at its highest modulation and coding rate (64-QAM, 3/4 coding) while 
the Mesh device is transmitting, would require the separation to be at least 20 m (instead of the 5 m used). 
For 16-QAM, 1/2 coding, the separation would be 10 m. 

B.2.4.2.1.2 "Across the street" analysis (2) 

Another critical consideration is the analysis of illumination of indoor RLANs in adjacent buildings. This is 
due to the fact that despite the larger distance, normally only one isolating building layer (which may also be 
a window) is situated in-between, and the Mesh antenna gain increases with the angle from the vertical axis. 

It is assumed for this scenario that the street is 10 m wide, which gives an antenna gain of -15 dBi and an 
outdoor distance of V 125 = 11.2 m. The structural isolation plus attenuation due to multipath/scattering is 
assumed to be 10 dB (window plus some indoor scattering). The total attenuation is then 
10+20*logl0(4*7t*d*f()/c) = 78 dB. Taking into account the antenna gain, the backoff and the Mesh activity 
factor of the Mesh node reduces the average level at the RLAN to -78 dBm. 

Of course, the numbers in the above analysis fluctuate by a number of decibels for individual deployments. 
The average structural attenuation was quoted to be 13.4 dB in ERC Report 72 [B12], but there may be 
variations in building height or terrain sloping that increase the antenna gain in the direction of the RLAN by 
a few dBs. Typically the above results of this subclause are broadly applicable as conservative estimates to a 
wide range of deployment scenarios. 

Power-control and DFS can assist in further reducing these interference levels. Note that the transmit 
probability of the RLAN device, (13 dB), has not been taken into consideration. 

B.2.4.2.2 Outdoor RLAN analysis 

An argument often used against the use of B WA devices in the 5-GHz bands is that it will interfere with out- 
door deployments of RLAN devices. It is quite obvious that co-location of these two types of devices on a 
roof (or neighboring roofs) will cause severe interference when operating in the same channel; however, it 
should be realized that exactly the same issue exists when two RLAN APs on a roof (or neighboring roofs) 
are competing for the same channel. (To be specific, this is mostly the case for HIPERLAN/2, which is 
schedule based). Attempting to avoid this type of interference, which works well for low duty cycles, IEEE 
802.11a uses CSMA/CD. In both cases, the requirement for a DFS mechanism can gracefully resolve the 
problem. In addition, outdoor RLAN deployments are predominantly used for hot-spot coverage and bridg- 
ing, which implies the use of down-tilted antennas and oftentimes geographical isolation for hot-spot cover- 
age and very directive antennas for bridging, each of which reduces the interference potential. In the cases 
where RLANs are currently used for access provisioning, WirelessHUMAN-compliant systems will likely 
not be deployed or be used as more efficient substitutes. 



Copyright ©2004 IEEE. All rights reserved. 



801 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



BWA deployments require broad coverage and reasonable frequency reuse numbers to maintain sufficient 
SNR plus limited DFS flexibility to avoid local interference sources. Therefore, the likelihood of roof- 
mounted RLAN devices unable to find a sufficient noise-free channel for proper operation are rather small. 

B.2.4.2.3 Network analysis 

To illustrate the interference analysis further, a typical scenario consisting of a 4-node indoor RLAN 
network and a nearby 4-node Mesh network, is examined. 

From Annex 2 of ERC Report 72 [B 12], it can be extracted that the typical indoor attenuation on top of free- 
space attenuation at 5 m is 4 dB for a mixture of LOS through NLOS scenarios. The additional attenuation 
through one wall is 7.1 dB and the additional attenuation through two walls is 12.5 dB (the walls in these 
cases were breeze blocks and the rooms contained both wooden and metal furniture). The attenuation 
through a double-glazed window was found to be 7 dB. 

In the case under study, a SU is assumed from each of these cases in a Small Office setting. The SU in the 
same room is assumed at 10 m; the SU in the adjacent room at 30 m; and the SU behind two walls at 50 m. 

The Small Office is assumed to be a single-floor building with a flat roof. The attenuation through the roof is 
22 dB. A typical indoor cross-floor attenuation according to Annex 2 of ERC Report 72 [B12] is 19 dB, 
which is probably a fairly pessimistic value. The Mesh #4 node is situated on the roof directly atop AP #1 
and provides the "Internet access" for the RLAN service within the building. The cabling distance between 
the data gathering point, the AP, and the access service, Mesh #4 node, is shortest. The distance between AP 
#1 and Mesh #4 is assumed to be 5 m. 

The nearest neighboring node, Mesh #1, is 50 m away on an adjacent building. The building attenuation is 
10 dB (a window plus indoor scattering, as in B. 2.4.2. 1.2. It is assumed that this building is lower than the 
building with the RLANs, resulting in an antenna gain of -10 dBi in the direction of the RLANs, rather than 
the -15 dBi specified in Table B.4). Two other nodes are each 200 m away as shown in Figure B.4. All Mesh 
nodes are on the roof and hence only have free-space (FS) attenuation to each other. Mesh #3 is assumed to 
have an additional 15 dB obstruction to the RLANs in the form of a building (basically the building on 
which Mesh #2 is located). 
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Note that in the Path Losses in Figure B.4, the antenna gain of the Mesh nodes (see Table B.4) in the direc- 
tion of the RLANs has been included. 



200 m FS 




m FS 



Path 


Path Loss 


Mesh#l 


-AP#1 


50m FS 


+ 28dB 


Mesh#l 


- RLAN#1 


60m FS 


+ 28dB 


Mesh#i 


- RLAN#2 


70m FS 


+ 28dB 


Mesh#l 


- RLAN#3 


80m FS 


+ 28dB 


Mesh#2 


-AP#1 


250m FS 


+ 33dB 


Mesh#2 


- RLAN#1 


250m FS 


+ 33dB 


Mesh#2 


- RLAN#2 


260m FS 


+ 33dB 


Mesh#2 


- RLAN#3 


270m FS 


+ 33dB 


Mesh#3 


- AP#1 


450m FS 


+ 48dB 


Mesh#3 


- RLAN#1 


450m FS 


+ 48dB 


Mesh#3 


- RLAN#2 


460m FS 


+ 48dB 


Mesh#3 


- RLAN#3 


470m FS 


+ 48dB 


Mesh#4 


-AP#1 


5m FS 


+ 52dB 


Mesh#4 


- RLAN#1 


52m FS 


+ 48dB 


Mesh#4 


- RLAN#2 


32m FS 


+ 48dB 


Mesh#4 


- RLAN#3 


12m FS 


+ 52dB 



Figure B.4— Example network scenario 



In Table B.17, the ranges and corresponding total link attenuations, which are assumed to be symmetrical, 
are gathered. In general, it can be observed that only nodes that are really close or in LOS through little 
attenuation (particularly windows) result in significant interference. 



Table B.17— Link attenuations and ranges 





Link attenuation/Range 




Mesh #1 


Mesh #2 


Mesh #3 


Mesh #4 


AP#1 


RLAN #1 


RLAN #2 


RLAN #3 


Mesh#l 




200 m 


400 m 


50 m 


50 m 


60 m 


60 m 


60 m 


Mesh#2 


94 dB 




200 m 


220 m 


220 m 


230 m 


230 m 


230 m 


Mesh#3 


100 dB 


94 dB 




450 m 


450 m 


460 m 


460 m 


460 m 


Mesh#4 


82 dB 


94 dB 


101 dB 




5 m 


52 m 


32 m 


12 m 


AP#1 


110 dB 


127 dB 


149 dB 


106 dB 




50 m 


30 m 


10 m 


RLAN#1 


111 dB 


128 dB 


149 dB 


130 dB 


94 dB 




50 m 


20 m 


RLAN#2 


111 dB 


128 dB 


149 dB 


126 dB 


84 dB 


132 dB 




30 m 


RLAN#3 


111 dB 


128 dB 


149 dB 


121 dB 


72 dB 


94 dB 


107 dB ! 
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In Table B.18, the maximum power and EIRP values for each of the devices is shown. For the RLAN 
devices and their AP, values are chosen that reflect implementations that are currently available in the 
market. 



Table B.18— Tx Power, conducted and EIRP (regulatory limited) 





AP 


RLAN 


Mesh ! 


Tx Power (mW) 


200 


200 


500 


Antenna (dBi) 


2 


0 


8 


EIRP (dBm) 


25 


23 


35 



In Table B.19, the resulting received signal strengths are shown assuming transmission with EIRP values as 
shown in Table B.18. Note that especially between the Mesh nodes, the Rx values are extremely high, which 
would automatically be reduced by the AGC. For simplicity of computation, this is however ignored. This 
table is not symmetric since different antenna gains at each end can affect the perceived signal level. 



Table B.1 9— Received Signal Levels (dBm) 





Mesh #1 


Mesh #2 


Mesh #3 


Mesh #4 


AP#1 


RLAN #1 


RLAN #2 


RLAN #3 


Mesh #1 




-54 


-60 


-42 


-80 


-83 


-83 


-83 


Mesh #2 


-54 




-54 


-54 


-97 


-100 


-100 


-100 


Mesh #3 


-60 


-54 




—61 


-119 


-121 


-121 


-121 


Mesh #4 


-42 


-54 


-61 




-84 


-102 


-98 


-93 


AP#1 


-76 


-93 


-115 


-80 




-72 


-62 


-50 


RLAN#1 


-79 


-96 


-117 


-98 


-72 




-112 


-74 


RLAN#2 


-79 


-96 


-117 


-94 


-62 


-112 




-87 


RLAN#3 


-79 


-96 


-117 


-89 


-50 


-74 


-87 





Table B.20 shows resulting sustainable modulations. The top row in each box shows the actual 
communication direction, the used modulation and the Noise threshold. The next four rows illustrate the 
effect of interference from each source (using maximum allowed EIRP). If the modulation differs from the 
top box, then switch to a more robust modulation scheme was mandatory to maintain 3% PER. The last 
column defines the interference margin. A positive value means the threshold has been exceeded and is 
shown in bold. 
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Table B.20 — Sustainable modulation during interference 



RLAN#1 
=>AP#1 


3/4 QPSK 


-90 




RLAN#2 
=>AP#1 


2/3 64-QAM 


-95 




RLAN#3 
=>AP#1 


3/4 64-QAM 


-95 


Mesh #1 


PER>3% 


4 


Mesh #1 


1/2 QPSK 


-5 




Mesh#l 


1/2 OPSK 


_5 


Mesh #2 


3/4 QPSK 


-13 


Mesh #2 


2/3 64-QAM 


-22 




Mesh #2 


O/'i £A HAM 


— zz 


Mesh #3 


3/4 QPSK 


-35 


Mesh #3 


2/3 64-QAM 


-44 




Mesh #3 


3/4 64-QAM 


44 


Mesh #4 


PER>3% 


0 


Mesh #4 


3/4 QPSK 


-9 




Mesh #4 


3/4 QPSK 


-9 


AP#1 => 
RLAN#1 


3/4 QPSK 


-90 




AP#1 => 
RLAN#2 


2/3 64-QAM 


-95 




AP#1 => 
RLAN#3 


3/4 64-QAM 


-95 


Mesh #1 


PER>3% 


1 




Mesh#l 


3/4 QPSK 


-8 


Mesh#l 


3/4 QPSK 


-8 


Mesh #2 


3/4 QPSK 


-16 


Mesh #2 


3/4 64-QAM 


-25 


Mesh #2 


3/4 64-QAM 


-25 


Mesh #3 


3/4 QPSK 


-37 


Mesh #3 


3/4 64-QAM 


-46 


Mesh #3 


3/4 64-QAM 


-46 


Mesh #4 


3/4 QPSK 


-18 


Mesh #4 


2/3 64-QAM 


-23 


Mesh #4 


3/4 16-QAM 


-18 



From Table B.20, two observations can be generalized. The first is that in certain scenarios interference is 
unavoidable if DFS is not used. The second is that interference only occurs when nodes are really close 
(such as Mesh #4) or have relatively good LOS properties (such as Mesh #1, which only has a window in- 
between and a reduced height antenna) to the RLAN network. The later generalization means that very few 
nodes in a Mesh network will cause degradation of a RLAN network. Realizing that the interference excess 
is relatively low, and the Mesh network uses power-control to reduce the EIRP where possible, interference 
from a transmitting Mesh device will be very limited. Combined with the activity factors for both devices 
(on average 13 dB each) and DFS mechanisms, the likelihood of interference becomes so small that it is 
easily handled with Automatic Repeat Request (ARQ) causing minimal degradation of performance. 

B.2.4.2.4 Adjacent channel issues 

A feature of the OFDM technology used in both RLANs and Mesh technology at 5 GHz, is that the adjacent- 
channel rejection is very high, at least 35 dB (see 8.3.11.2), Since the interference levels between RLANs 
and Mesh devices are relatively low compared to this, it is reasonable to assume that adjacent channels using 
RLAN and Mesh technology will not cause any noticeable interference to each other; therefore, this requires 
no further consideration. 

B.2.4.3 Interference to RTTT 

In accordance with CEN/TC 278 prEN 12253 [B5] and ERC Report 72 [B12], the cross-polarization is 
assumed to be 10-15 dB to the RSU and 6-10 dB to the OBU (Table B.21 uses the lower numbers). 



Table B.21 — Needed separation distance Mesh to RSU and OBU 



Parameter 


RSU 


OBU 


Pt 


6 


6 


B Rx 


10 5 


10 


Bi 


22 


22 
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Table B.21— Needed separation distance Mesh to RSU and OBU (continued) 



Parameter 


RSU 


OBU 


I Rx =Rx sens~ C/I 8PSK 


-117 


-90 


L 


119.6 


116.6 


92.6 


Cross-polarization 


10 


6 


Antenna and feeder gain 


8 


8 


Separation distance 


553 


394 


53 1 



It should be noted that in the above calculations of Table B.21, the duty cycle of the Mesh devices, which 
significantly reduces the interference scenario, has not been taken into consideration. 

Especially for the RSU case, where the separation distance is fairly significant, it can be shown that the 
interference to the Mesh device is significantly larger than the other way around. Since RTTT devices 
normally have a fairly high duty cycle, a close Mesh device would not be able to operate properly in this 
channel and would need to use the DFS mechanisms to switch to another channel. Therefore, for RSUs, 
proper operation is virtually guaranteed by virtue of its own interference potential. 

B.2.4.4 Interference to radar 

For radars, a somewhat similar situation exists as with RTTT RSUs. To show this, the interference distance 
from radars into Mesh devices is derived, followed by the derivation of the interference distance from Mesh 
devices into radars. Comparing Table B.22 and Table B. 23, the interference distance from radars to Mesh is 
much larger than the interference distance from Mesh to radars. 

For analysis of the minimum distance at which an Mesh device still operates, shown in Table B.22, the most 
robust modulation and coding mode is used. 



Table B.22— Minimum separation distance of radar to Mesh 



Radar type 


A 


B 


C 


D 


E 




Peak EIRP 


98.6 


26 


60 


93 


97 


dBW 


Antenna gain 


40 


0 


46 


43 


43 


dBi 




58.6 


26 


14 


50 


. 54 


dBW 


Bandwidth radar 


3 


15 


30 


14 


3 


MHz 


1 mesh =Rx sens~ C/I BPSKI/2 


-116 


dBW 


L 


174.6 


142.0 


131.3 


166.0 


170.0 


dB 


Gain and feeder loss 


48 


8 


54 


51 


51 


dB 


Propagation loss 


222.6 


150 


185.3 


217 


221 


dB 


Distance at 5.5 GHz 


20693 


137 


497 


11813 


17630 


km 


Radio horizon 


51.4 


346.6 


51.4 


51.4 


51.4 


km (see [Bll]) 


Separation distance 


51.4 


137 


51.4 


51.4 


51.4 


km 
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In Table B.23, the thermal noise level has been assumed -204 dBW/Hz whereas the Rx noise factor is 
assumed to be 5 dB. The maximum I/N is -6 dB as specified by NATO (see ERC Report 72 [B12], ERC 
Report 15 [Bll]). 



Table B.23— Minimum separation distance of Mesh to radar 



Radar type 


A 


B 


C 


D 


E 




P t mesh 


-2 


dBW 


Bandwidth radar 


3 


15 


30 


14 


3 


MHz 


Noise (dBW) 


-134.2 


-127.2 


-124.2 


-127.5 


-134.2 


dBW 


On-tune rejection 


-8.9 


-1.9 


0.0 


-2.2 


-8.9 


dB (see [B12]) 


Max. Interference 


-131.3 


-131.3 


-130.2 


-131.3 


-131.3 


dBW 


L 


129.3 


dB 


Gain + feeder loss 


48 


8 


54 


51 


51 


dB 


Propagation loss 


177.3 


145.3 


191.6 


188.3 


188.3 


dB 


Distance at 5.5 GHz 


220.1 


79.4 


916.3 


662.7 


662.0 


km 



Comparing the required distances at 5.5 gHz from Table B.22 and Table B.23, it is shown that in all cases, 
the separation distance is larger for the BWA system, forcing it effectively out of the channel used by the 
radar. In all cases, the separation distance is effectively limited by the radio horizon. 

In the case of radar type B, which is airborne, depending on the exact location of the radar, the gain+feeder 
loss will reduce from +8 to -22 dB, significantly reducing the necessary separation distance. Since the angle 
of detection (if any) is not known, this factor has not been used in the previous tables. For the other types, 
the distance is limited by the radio horizon, but in practice likely much lower due to obstructions and clutter. 

From Table B.22 and Table B.23, similar conclusions to the RLAN analysis in ERC Report 72 [B12] can be 
drawn. Sharing with maritime radars (which are not likely operating anywhere near residential areas) and 
S5.452 meteorological radars in band B, and radiolocation radars in both band B and C is feasible when an 
effective DFS mechanism is employed by the Mesh system and the radar density is not too high. 

B.3 Performance characteristics 
B.3.1 WirelessMAN-SCa PHY throughput 

Table B.24 indicates the raw bit rates delivered by the WirelessMAN-SCa PHY for typical bandwidths and a 
roll-off of 0.25, while Table B.25 indicates the raw bit rates for a roll-off of 0.15. 

The raw bite rate (in Mb/s) is defined as shown in Equation (159). 

(BW-0m*)BpmR outer -R inner 

(1+a) ( yj 

where 



Copyright ©2004 IEEE. All rights reserved. 



807 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



BW is the bandwidth in MHz, 
a is the roll-off, 

Bpm is the number of bits per modulation symbol, 
Router = 239/255 is the outer (Reed-Solomon) code rate, 

R inner is the inner (TCM) code rate that specified in the first column of each table. 
Table B.24— WirelessMAN-SCa raw bit rates (Mb/s) for 0.25 roll-off 



Modulation and 
inner coue r«iic 


6 MHz 


7 MHz 


20 MHz 


BPSK 1/2 


2.22 


2.59 


7.47 


BPSK 3/4 


3.32 


3.89 


11.20 


QPSK 1/2 


4.43 


5.18 


14.93 


rvnev O/l 

l^ri>K 2/3 


^ 01 
j.Vl 


£ Q1 


1 Q 01 


QPSK 3/4 


6.65 


7.77 


22.40 


QPSK 5/6 


7.39 


8.64 


24.88 


QPSK 7/8 


7.76 


9.07 


26.13 


16-QAM1/2 


8.87 


10.37 


29.86 


16-QAM 3/4 


13.30 


15.55 


44.79 


64-QAM 2/3 


17.73 


20.73 


59.72 


64-QAM 5/6 


22.16 


25.91 


74.65 | 


256-QAM 3/4 


26.60 


31.10 


89.58 


256-QAM 7/8 


31.03 


36.28 


104.51 



Table B.25— WirelessMAN-SCa raw bit rates (Mb/s) for 0.15 roll-off 



Modulation and 
inner code rate 


6 MHz 
(MMDS) 


7 MHz 
(ETSI) 


20 MHz 
(UNH) 


BPSK 1/2 


2.41 


2.82 


8.11 


BPSK 3/4 


3.61 


4.22 


12.17 


QPSK 1/2 


4.82 


5.63 


16.23 


QPSK 2/3 


6.42 


7.51 


21.64 


QPSK 3/4 


7.23 


8.45 


24.34 


QPSK 5/6 


8.03 


9.39 


27.05 


QPSK 7/8 


8.43 


9.86' 


28.40 


16-QAM 1/2 


9.64 


11.27 


32.46 


16-QAM 3/4 


14.45 


16.90 


48.69 


64-QAM 2/3 


19.27 


22.53 


64.91 | 
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(continued) 



Modulation and 
inner code rate 


6 MHz 
(MMDS) 


7 MHz 
(ETSI) 


20 MHz 
(UNA) 


64-QAM 5/6 


24.09 


28.17 


81.14 


256-QAM 3/4 


28.91 


33.80 


97.37 


256-QAM 7/8 


33.73 


39.43 


113.60 



B.3.2 WirelessMAN-OFDM/OFDMA PHY symbol and performance parameters 

The effective bandwidth of the transmitted signal is related to the subcarrier spacing and the number of sub- 
carriers. 

In order to calculate the sampling frequency for any bandwidth, the bandwidth efficiency is defined as 
shown in Equation (160). 

^Efficiency' ^ ' ~ Jf^ (160) 

where 

is the Channel bandwidth (Hz), 
is the Sampling frequency (Hz), 
is the Subcarrier spacing (Hz), 

is the Number of active subcarriers used in the FFT (pilot and data subcarriers) + DC 
subcarrier, 
is the FFT size. 



BW 

N FFT 



The bandwidth efficiency is designed to be in the range of 83-95%, depending mainly on the FFT size, in 
order to occupy the maximum usable bandwidth but still allow adequate RF filtering. 

The following tables give some calculations of the subcarrier spacing, symbol duration and CP duration for 
different masks. The sampling rate is defined as F s = BW- 8/7, except for 256-OFDM (see 8.3.2.4) in 
licensed bandwidths, which are not a multiple of 1.75 MHz. In those cases, the sampling rate is 
F s = BW7/6. 
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Table B.26— OFDM channelization parameters for licensed bands 



Bandwidth 
(MHz) 


OFDM ( N FFT = 256) 


A/(kHz) 




r f (ii«) 




V 32 


T b /\6 


V 8 




MMDS (n = 86/75) 


1.5 


a 23 
6 32 


148 43 


4 28 

4 43 


q 13 

9 43. 


18 26 
18 43 


36 43 


3.0 


13 l6 


74 43 


o 14 
2 43 


d 28 
4 43 


q 13 
9 43 


IS 26 
18 43 


6.0 


5 


9 

37 43 


! 43 


2 43 


4 43 


9 43 


12.0 


co 3 

53 4 \ 


18 43 


25 
43 


, 7 
X 43 


? 14 

• 2 43 


4 28 
4 43 


24.0 


im 1 
107- 


q 13 
9 43 


25 
86 


25 
43 


, 7 
! 43 


2 43 


ETSI (n = 8/7) 


1.75 


-13 
7 — 
16 


128 


4 


8 


lo 


'JO 


3.5 


15 8 


64 


2 


4 


8 


1 a 

Id 


/.u 


31 4 


32 


1 


2 


4 


Q 
O 


14.0 


62 2 


16 


1 

2 


1 


2 


4 


28.0 


1 


o 

o 


1 
4 


1 
2 


l 


2 


WCS (n = 144/145) 


2.5 


»j 


88? 






"5 


-i 


5.0 




"t 




A 


5 I 


"i 


10.0 


45 


4 


25 
36 


'i 


»5 


s t 


15.0 






20 
43 


40 

43 ' 


4, 
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Table B.27 — OFDM A channelization parameters for licensed bands 



Bandwidth 
(MHz) 


OFDMA(^ r =2048) 






T,(U«) 


V32 




T„/i 




MMDS (f/BW= 8/7) 


1.5 


36 
43 


1194? 




"•1 


149| 


298? 


3.0 


60 
89 


597^ 


■4 


»i 




1491 


6.0 


23 


298? 




«! 




»! 


12.0 


56 


149-1 




'1 


"! 




24.0 


nil 

28 


A 


A 


4 I 


•S 


,s| 


r- 
\ 
oo 

II 

\ 

w 


1.75 


83 
85 


1024 


32 


64 


128 


256 


3.5 


1« 

64 


512 


16 


32 


64 


128 


7.0 


3?? 
32 


256 


8 


16 


32 


64 


14.0 | 




128 


4 


8 


16 


32 


28.0 




64 


2 


4 


8 


16 


r- 

\ 

00 

II 

St 

\ 

55 

CO 


2.5 


81 






«! 


89 5" 


179j 


5.0 


2^ 
81 


2 

358^ 




»? 


44l 


89? 


10.0 


5^Z 
81 


179i 




"i 


22? 


44* 




15.0 


27 


119 b 


3 H 


'A 




2912 

15 
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Table B.28 — OFDM/OFDMA channelization parameters for license-exempt bands 





OFDM 


OFDMA 




n 


144/25 


8/7 


Bandwidth 
(MHz) 


N FFT 


256 


2048 




Aft kHz) 


45 


81 






22? 
9 


179 i 
5 




r,ou) 


32 


25 
36 


5? 
5 






T b 
16 


iH 


111 
5 






8 


2 z 

9 


22? 
5 






n 

4 


5 5 
9 




20 


A/(kHz) 


90 


56 






"i 


»; 




r,(|U) 


32 




»S 






16 


25 
36 








8 


>i 


»J 






4 




-I 



In Table B.29, raw bit rates are shown for typical band widths. The raw bite rate is defined as 
N used ' b m ' C / T s > wnere b m is the number- of bits per modulation symbol and c r is the coding rate. 



Table B.29— OFDM/OFDMA raw bitrates (Mb/s) 



Bandwidth 
(MHz) 


T 8 


BPSK 
1/2 


QPSK 
1/2 


QPSK 
3/4 


16-QAM 
1/2 


16-QAM 
3/4 


64-QAM 

2/3 


64-QAM 
3/4 




OFDM 256-FFT 




6 MHz 


T b /32 


2.50 


5.00 


7.51 


10.01 


15.01 


20.01 


22.52 


(MMDS) 


V16 


2.43 


4.86 


7.28 


9.71 


14.57 


19.43 


21.85 




T b n 


2.29 


4.59 


6.88 


9.17 


13.76 


18.35 


20.64 




V 4 


2.06 


4.13 


6.19 


8.26 


12.38 


16.51 


18.58 
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Table B.29 — OFDM/OFDM A raw bitrates (Mb/s) 



lEEEStd 802.16-2004 



7 MHz 
(ETSI) 


V32 


2.92 


5.82 


8.73 


11.64 


17.45 


23.27 


26.18 


T b /\6 


2.82 


5.65 


8.47 


11.29 


16.94 


22.59 


25.41 


r b n 


2.67 


5.33 


8.00 


10.67 


16.00 


21.33 


24.00 


V 4 


2.40 


4.80 


7.20 


9.60 


14.40 


19.20 


21.60 


20 MHz 
(U-NII) 


T b /\6 


8.13 


16.26 


24.40 


32.53 


48.79 


65.05 


73.19 j 


T b /% 


7.68 


15.36 


23.04 


30.72 


46.08 


61.44 


69.12 


T b /4 


6.91 


13.82 


20.74 


27.65 


41.47 


55.30 


62.21 


OFDMA 2048-FFT 


6 MHz 
(MMDS) 


T b /32 




4.99 


7.48 


9.97 


14.96 


19.95 


22.44 


T b /\6 




4.84 


7.26 


9.68 


14.52 


19.36 


21.78 


T b n 




4.57 


6.86 


9.14 


13.71 


18.29 


20.57 


T b /4 




4.11 


6.17 


8.23 


12.34 


16.46 


18.51 


7 MHz 
(ETSI) 


T b /32 




5.82 


8.73 


11.64 


17.45 


23.27 


26.18 


T b /\6 




5.65 


8.47 


11.29 


16.94 


22.59 


25.41 


T b n 




5.33 


8.00 


10.67 


16.00 


21.33 


24.00 


T b /4 




4.80 


7.20 


9.60 


14.40 


19.20 


21.60 
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B.4 Frequency reuse of 1 for OFDMA 

This subclause defines extensions of OFDMA system for working in deployment scenarios with frequency 
reuse of 1. 

B.4.1 Introduction 

The definition of an OFDMA system as defined in 8.4 is well suited to work with deployment scenarios with 
frequency reuse factor >1, but in order to satisfy requirement of reliability, coverage, capacity, spectral effi- 
ciency, and location base service. The system can be configured to work in a reuse of 1, which means the 
same RF frequency is allocated to all sectors in the cell. In this case, a new scheme of work must be intro- 
duced in order to achieve the needed performance. A scenario using a reuse of 1 is given in Figure B.5: 




Figure B.5— Reuse of 1 configuration, 3 sectors per cell 

There are three options of operation in the reuse of 1 scenario: 

— Asynchronous configuration— In this configuration, every base-station uses its own permutation, the 
frame lengths and starting times are not synchronized among the base- stations. Therefore, orthogonality 
is kept within the base-station but not between base-stations. In this scenario, the base-stations could be 
synchronized or not to the same reference clock. This mode will introduce interference between base- 
station (subcarriers from different subchannels collide in a controlled way, determined by the different 
permutations). This configuration could be easily used as an independent low-cost hot spot deployment 
(as an example). 

— Synchronous configuration —In this configuration, all base-stations use the same reference clock (for 
example, by using GPS), the frame durations and starting times are also synchronized among the base- 
stations but still each base station uses different permutations. Therefore, the time/frequency orthogo- 
nality is kept between and within the base-stations operation but still interference between the same 
subchannels of different base-station occurs. Due to the time synchronization in this scenario and the 
long symbol duration of the OFDMA symbol, fast handoff as well as soft handoff is possible. This con- 
figuration could be used as an independent base-stations deployment with a controlled interference level 
(as an example). 

— Coordinated Synchronous configuration— In this configuration, all base-stations work in the syn- 
chronous mode but use also the same permutations. An upper layer is responsible for the handling of 
subchannels allocations within the sectors of the base-station, making sure that better handling of the 
bandwidth is achieved and the system could handle and balance load between the sectors and within the 
system. This mode is identical in performance as the regular coverage scenarios, beside the fact that the 
bandwidth allocated to each sector is only a portion of the overall bandwidth, but when using the load 
balancing additional system gain is achieved. This configuration could be used as a full scale system 
deployment, with a common backbone (as an example). 
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The preferred scenario is the Coordinated Synchronous mode (when using this configuration with different 
permutations per base-station we get the synchronous mode, and do not use a synchronized clock between 
the base stations as well we end up with the asynchronous mode of operation); the configuration of the base- 
station sectors are presented in Figure B.6 




Figure B.6— Reuse of 1 configuration, 3 sectors per cell 
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B.5 FLI modulation codeword sequences for AAS Direct Signaling Method 

The following list contains 8064*2 FLI modulation codeword sequences, first codeword representing in- 
phase and second codeword representing quadrature-phase. 

FLI Codeword sequence = 

0x5bbf,0x47cc,0x66b7,0x5elf,0x2787,0x2256,0xlf04^ 

91,0x7a89,0x6cd8,0x035c,0xla8f,0x6300,0x5776,0x4flc,0x712e,0x3e7f,0x36af,0x6922,0x23b5,0x658d,0 

X4781,0x4ee8,0x0955,0x594d,0x328a,0xl9a2,0x034b,0x0454,0x7148,0x74d4,0x5d43,0x343b,0x677f,0xl 

239,0x2de8,0xll65,0xlddd,0x2863,0x760d,0xl799,0xl086,0x6978,0x7386,0x5a2d,0x282e,0x7edd,0xll6 

5,0x4f6d,0x35f3,0xl80c,0xl7c3,0x4247,0x7537,0x786c,0x40ef,0x52cl,0x5971,0x23ef,0x20e9,0x724e,0x 

7c62,0x4564,0x6423,0x35e4,0xl239,0x6el6,0x61d9,0x61e5,0x3bae,0x7f29,0x0734,0x4490,0x6bfb,0x257 

5,0x4ea5,0x2dd4,0x0ce2,0x5e34 5 0x2230,0x7ac4,0x35a9,0x01ae,0x5e6e,0x088a,0x5024,0x208f,0x3e25,0x 

14b4,0x27dd,0x4da3,0x5f8d,0x27ac,0x5ba8,0x0ba7,0x3fc6,0x77a3,0x7b41,0x715f,0x6b9d,0x3a00,0x438f 

,0x097e,0x5900,0x 1 1 59,0x224 1 ,0x 1 85 6,0x2b72,0x4 1 56,0x4604,0x2da5 ,0x3cb 1 ,0x375b,0x 1 c29,0x5bf2,0x 

7174,0x071f,0x2121,0x7aa2,0x44bb,0x79d5,0x757a,0x337e,0x06fc,0xl78e,0x4a97,0x301e,0x529b,0x5d0 

e,0x3bf4,0x3e32,0xl263,0x4ec3,0x724e,0x06eb,0xlf49,0x7c38,0x4b2e,0xleaa,0x31a7,0xldf6,0x43a4,0x 

5d25,0x43c2,0x5593,0x52ea,0xl989,0xl86a,0x4828,0x38e5 5 0x3693,0x0e4a,0x4abc,0x3701,0x395c,0x279 

0,0x08ec,0x7b27,0x6d61,0x55de,0x5467,0x77ee,0x0708,0x761a,0x7097,0x602d,0x3c8d,0x6a33,0x7blb,0 

X7d81,0xlddd,0x003c,0xl66d,0x51fb,0x23f8,0x55b8,0x780a,0x08c7,0x757a,0x5a77,0x6a33,0x7080,0x54 

3d,0x32ec,0x602d,0xl651,0x4c0d,0x2b3f,0xl3cd,0x342c,0x36e2,0x40b5,0xl531,0x66a0,0x462f,0x069a,0 

X4675,0x20fe,0x632b,0x5042,0x0caf,0x5416,0x4f7a,0x0d67,0x712e,0x7ddb,0x5b94,0x47aa,0x6fde,0x0ft 

e, 0x6e4c,0x29da,0x43b3,0x7c75,0x44ca,0x3cd7,0x3333,0x5707,0x7c5e,0x7a89,0x08ec,0x605c,0x715f,0x 
74d4,0x7080,0x4247,0x575d,0x2a86,0xl9a2,0x47f0,0x65a6,0x44el,0x669c,0xlafe,0x3d6e,0x79c2,0x38b 

f, 0x4675,0x70ab 5 0x40a2,0x3bae,0xl4c5,0x38a8,0x5feb,0x4247,0x0d01,0x3078,0x36c9,0x2acb,0x2clc,0x 
0311 ) 0x089d,0x4662,0x05a0,0x3e68,0x6d07,0x3324,0x0933,0x4991,0x2504,0x7ef6,0x2c0b,0x27el,0x73 
86,0x4afl,0x5a3a,0x7b30,0x49dc,0x5be5,0x0e4a,0x7cl3,0x2acK^ 
1637,0x2eb4,0x4b48,0x3b92,0x2562, 

0xl0e0,0x7cl3,0x49ba,0x70da,0x0294,0x6a0f,0x61d9,0x6183,0x6e70,0x0caf,0x0e5d,0x6e67,0xl799,0x4 

df9,0x0942,0xl3ab,0x32c7,0x7eac,0x5a3a,0x77b4,0x20a4,0x0cde,0x7e87,0x24cc,0x6944,0x4828,0x4d9f, 

0x2098,0x7148,0x220c 5 0x221b,0xl531,0x6dl0,0x74ff,0x68a7,0x3a00,0xl4f9,0x36f5,0x2bl4,0x49ad,0x4 

4bb,0x4b48,0xl540,0xl80c,0x5885,0x4859,0x7499,0xll3f,0x43d5,0x2136,0xl646,0x5682,0x51ec,0x073 

4,0x2787,0x5d32,0x47cc,0x3bb9,0x3dlf,0x0942,0x4564,0x3d79,0x6b9d,0xl25f,0x5353,0xl0cb,0x4250,0 

X52d6,0x076e,0x65fc,0x6317,0x5bf2,0x56d8,0x6ca9,0x6faf,0x2c6d,0xll3f,0x239e,0x3369,0x40c4,0xlb2 

I,0x4ae6,0xld90,0xlc3e,0x24aa,0x77ee,0x2504,0x20c2,0x2c51,0xlf5e,0x74e8,0x0708,0x7163,0x6e67,0x 

766b,0x0942,0xin5,0x0a78,0x5055,0x7821,0x3bae,0x6d3b,0x7de7,0x6366,0x0f82,0x4604,0x7265,0x0d5 

b,0x38d9,0x3bf4,0x74b2,0x227d,0xl50d,0x58f4,0x7d96,0x4eb2,0x282e,0x7ac4,0x40d3,0x7f58,0x6cr3,0x 

7631,0xl0e0,0x5fa6,0x6e2a,0x6e67,0x06d7,0x394b,0x7998,0x0el0,0x4ea5,0xll28,0xlac2,0x2230,0x08c 

7,0x4221, 0x5a4b,0x49ad,0x5bf2,0xl091,0x43fe,0x7 112^ 

5a3a,0x3977,0x2f26,0x35be,0x4487,0xlb7b,0x032d,0x5b94,0x47db,0x51al,0x328a,0xlcl5 5 0x73cb,0x24f 

0,0x79d5,0x2839,0x536f 5 0x0a22,0x51al,0x70cd,0x724e,0x5584,0x7203,0xl7b2,0x097e,0x330f,0x696f,0x 

1380,0x3318,0x40d3,0x2504,0x6al8,0xla98,0x3894,0xldac,0x635a,0x01f4,0x44bb,0x2658,0x7ac4,0x0bb 

0,0x5a5c,0x7eac,0x2241,0x2ea3,0x05c6,0x65fc,0x374c,0x6479,0x7657,0x08d0,0x4573,0x2790,0x4f51,0x 

5a60,0xl3e6,0x05dl,0x2e88,0x55de,0x7537,0x4573,0x7af8,0x2839,0x74a5,0x0c93,0xlebd,0x5elf,0x6a6 

9,0x38d9,0x7ebb,0x2997,0x20b3,0x634d,0x6743 5 0x5593,0x01b9,0x6a24,0x4c40,0xlddd,0x31ea,0x7c49,0 

X31a7,0x4ed4,0x2496,0x5f8d,0x5dl9,0x77c5,0x646e,0x23b5,0x3318,0xlf04,0x2575,0x62e3,0xlafe,0xl2 

12,0x7551,0x6a55,0x0ba7,0x670e,0x05fa,0x2147,0x3342,0x3f8b,0x6fde,0x004d,0x06eb,0x3d45,0x641f,0 

X74e8,0x7df0,0x52fd,0x0cde,0x593c,0x5fbl,0x7259,0x0017,0x27ca,0x3369,0x097e,0x3e54,0x3fdl,0x752 

0,0xl7ff,0x29fl,0x6d2c,0xlef0,0xlee^ 

872,0x5ced,0x4803,0x79b3,0x5a4b, 
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0x2dff,0x633c,0x3b85,px5bce,0x4089,0x77b4,0x688c,0x373d,0x0918,0x55c9,0x32b6,0x65eb,0x29da,0x0 
734,0x542a,0x06c0,0x5033,0xl81b ) 0x5344,0x02e5,0x2602,0x2af7,0x454f,0x6faf,0x6292,0x0c84,0x5b83, 
0x3906,0x748e,0x3716,0x4na,0x7f02,0x47f0,0x0723,0x5761,0x6452,0x3035,0x6bd0,0xll28,0x29bc,0x^ 
432,0x7e87,0x36e2,0x7f58,0xlc29,0x2c0b,0x6077,0x02bf,0x51d0,0x79fe,0x7520,0xl87d,0x7edd,0xlc02, 
0x47bd,0x 1 526,0x6978,0x 1 5 1 a,0x24bd,0x20a4,0x3 1 d6,0x43c2,0x2549,0x7499,0x5467 ,0x637 1 ,0x677f ,0x 
161c,0x3ca6,0x787b,0x7836,0x669c,0x7f64,0xl7e8,0x^^^^ 

0,0x0708 ,0x68b0,0x39 1 1 ,0x3053,0x39 1 1 ,0x226a,0x6ba 1 ,0x2b65 ,0x52c 1 ,0x5c9c,0x48 1 4,0x3d6e,0x5bbf ,0 

X484e,0x6fb8,0x4aab,0xlad5,0xlc58,0xl274,0x31cl,0x2549,0xlfl3,0x004d,0x465e,0x6ff^ 

7,0x519d,0x44el,0x4b5f,0x3693,0x29ab,0x36de,0x3d45,0xlf04,0xl4f9,0x544c,0x73e0,0x2256,0x2dd4,0x 

3el9,0x3693,0x3bae,0x0a22,0x507e,0x0ale,0x4490,0x2b03,0x4638,0x2f40,0x6292,0x641f,0x55af,0x644 

5,0x55b8,0x3324,0x6c95 ,0x007 1 ,0x6006,0x4649,0x0e 1 0,0x 1 53 1 ,0x0 1 e3 ,0x0969,0x06b 1 ,0x2f0d,0x5707,0 

X4c0d,0x7c75,0x6725,0x7c62,0x4c6b,0x6d61,0xlc3e,0x2848,0x4b05,0x5e08,0x7b30,0x7c49,0x61ce,0x3d 

If,0xl22e,0x6bc7,0x58df,0x65eb,0xleaa,0x3bc8,0x56e4,0x531e,0x77d2,0x06eb,0x0d5b,0x3e25,0x52ea,0 

X090f,0x688c,0x4127,0x6060,0x395c,0x7080,0xlb0a,0x528c,0x35d8,0x38a8,0x7c5e,0x74d4,0x033a,0xlc 

15,0x032d,0x0017,0x7c38,0x6e3d,0x7eca,0x6935,0x61f2,0x44ac,0x2f6b,0x52a7,0x575d,0x5695,0x410c,0 

x7e90,0x2848 ,0x66a0,0x 1 56b,0x7c04,0x097e,0x6434,0x 1 67a,0x 1 e8 1 ,0x6909,0x6fb8,0x748e,0x 1 205 ,0x2c 

7a,0x4986,0x5344,0x06c0,0x5309,0x7631,0x2ef9,0x0745,0x4acd,0x306f,0x595a,0x4f7a,0x74e8,0x2513,0 

X49cb,0x3e7f,0x6719,0x5d32,0x6f84,0x0f82,0x329d,0xl239,0x73ba,0x5f9a,0x6006,0x47bd,0x20d5,0x06 

8d,0x3bf4,0x633c,0xlc64,0x4c40,0x51al,0xin5,0xl4ee,0xlf62,0x4c6b,0x49f7,0x58e3,0x2ec5,0x5c8b,^ 

0cde,0xl0e0,0x2db2,0x059c,0x2629,0x2874,0x2e9f,0x61ce,0xlae9,0x3ca6,0x4afl,0x01c8,0x2150,0x410c 

,0x5470,0x6bal,0x003c,0x0bd6,0x4bl2,0x282e,0x24e7,0x0a35,0x23f8,0x536f,0x465e,0x4d88,0x507e,0x 

0ce2,0x2513,0xlll4,0x52fd,0x4f6d, 

0x6a42,0xlf2f,0xlac2,0x6e67,0x7eel,0x6732,0x2aba,0x0185,0x7b27,0x29cd,0x0b9b,0x4eff,0x23d3,0x43 

fe,0x285f,0x374c,0x35e4,0x61e5,0xlll4,0x7df0,0xl0cb,0x65d7,0xl7ff,0x7626,0x0745,0x7203,0xl7c3,0 

x4db4,0x3 8 83 ,0x6 1 a8 ,0x5 885 ,0x7d8 1 ,0x0e2c,0x4c3 1 ,0x7b 1 b,0x4c 1 a,0x6a42,0x7ad3 ,0x3fed,0x 1 a8f ,0x49 

cb,0x3a7 1 ,0x 1 9b5,0x4f0b,0x4dee,0x7b 1 b,0x35f3 ,0x5bce,0x7b56,0x2f26,0x 1 989,0x7e90,0x2 1 7b,0x3407,0 

X603a,0x6ccf,0x4f37,0x02e5,0x543d,0x27bb,0x4986,0x02d9,0x6006,0x089d,0xl25f,0x221b,0x3582,0x0b 

e a,0x344a,0x420a,0x20e9,0xlf2f,0x2256,0x27ca,0x6944,0x0d67,0x4529,0x5d32,0xlc02,0x2b59,0x35be,0 

Xl540,0x5018,0x23f8,0x2adc,0x58b9,0x6e4c,0x779f,0xlb6c,0x61bf,0x5069,0x73f7,0x750b,0x0e5d,0x0d 

67,0x780a,0x68cl,0x4814,0x220c,0x2b65,0xl7d4,0x0bfd,0x7228,0x4db4,0x6bb6,0x3333,0x4130,0x5ced, 

0x31fd,0x2481,0xl99e,0x3a3c,0x38d9,0x2812,0x7272,0x5710,0x62b9,0xl620,0x518a,0x0377,0x264f,0x3 

a7 1 ,0x4c57,0x2e9f ,0x6c82,0x3324,0x7 1 05 ,0x4e8e,0x01 b9,0x5 1 b6,0x29bc,0x 1 397,0x760d,0x5e79,0x20fe, 

0x4f20,0x3cd7,0x4872,0x6953,0x4d88,0xl3fl,0x2389,0x0360,0x2790,0xlc64,0x3410 5 0x3bc8,0x2f7c,0x3 

2c7,0x05fa,0x45 58,0x422 1 ,0x2 1 1 d,0x 1 e8 1 ,0x4236,0x7 1 05 ,0x7b 1 b,0x 1 ac2,0x4c3 1 ,0x08c7,0x5 1 fb,0x501 8 

,0x0e76,0x002b,0x6768,0x005a,0x3be3,0x3cd7,0x08al,0x5055,0x2997,0x6d76,0x5917,0xl9ef,0x5b83,0x 

604b,0x4c26,0x5378,0x0ff3,0x032d,0x20c2,0x3d52,0x7b41,0x74e8,0x2fla,0x6cd8,0x0b9b,0x5d54,0x263 

e,0x3cc0,0x255e,0x7ef 6,0x4e99,0x 1 540,0x5 695 ,0x05b7,0x4f 1 c,0x 1 aa4,0x4398,0x392d,0x2aba,0x 1 edb,0x 

Id87,0x211d,0x7af8,0x575d,0x7c75,0x43d5,0xlf49,0x2664,0x3960,0x2496,0x3d45,0x32ec,0x2615,0x397 

7,0xlcl5,0x7259,0x0283,0x35be,0x20b3,0x38ce,0x77f9,0xl856,0x658d,0xl557,0x2f31,0x3ceb,0xl86a,0 

x7dbd,0x427b,0x779f ,0x34 1 0,0x2dd4,0x0a22,0x3d 1 f ,0x4 1 7d,0x 1 c5 8 ,0x034b,0x343b,0x2c46,0x2db2,0x7f 

29,0x73dc,0x6285,0xll4e,0x069a,0x5dl9,0x3684,0x2e9f,0x05ed,0x4f51,0x4638,0x62df,0x79c2,0x5e45,0 

x779f ,0x6e2a,0x4f46,0x69 1 e,0x 1 8 1 b,0x4250,0x06a6,0x2f7c ,0x55e2,0x2 1 2 1 ,0x5fa6,0x 1 60b,0x20e9,0x0bc 

I,0x6d76,0x6317,0xll59,0x4991,0x604b,0x0185,0x5e6e,0x4acd,0x0d3d,0x5c8b,0xl827,0x5e79,0x4236,0 

X58f4,0x0071,0x08d0,0x6a55,0x3035, 

0x29bc,0x0924,0x52b0,0x2aba,0x5d0e,0x05c6,0x0f82,0x6d4a,0x605c,0x7aef,0x2b59,0x454f,0x01c8,0x26 

73,0x5378,0x6ce4,0x712e,0x0a35,0xl49f,0x6fe2,0x56be,0x2b72,0x3476,0x076e,0x454f,0x7ac4,0x77ee,0 

X3461,0x52d6,0x49e0,0x3894,0x040e,0x7391,0x68cl,0xl7e8,0x5e45,0x55f5,0xlad5,0x24cc,0x604b,0x77 

d2,0x73ba,0x712e,0x56be,0x545b,0x65a6,0x36de,0x2389,0x6754,0x49ba,0x4796,0x7080,0x7836,0x3ceb, 

0x6d4a,0x 1 263,0x5322,0x70e6,0x 1 25f,0x4dc5,0x40f 8,0x7de7 ,0x763 1 ,0x5d7f ,0x 1 b0a,0x4b05 ,0x4b63,0x7 

f73,0x748e,0x2adc,0x2c20,0x7f73,0x40c4,0x36f5,0x61ce,0x6452,0x77ee,0x632b,0x6953,0x56f3,0x4502, 

0x66dl,0xl637,0x66c6,0x4986,0x6e70,0x6ff5,0x483f,0x5309,0x2ed2,0x2adc,0xl7d4,0x0bfd,0x7998,0xl 

248,0x3c9a,0x01c8,0x4cla,0x6d76,0x2980,0x08b6,0xl4d2,0x2c6d,0x4abc,0x5cfa,0x62b9,0x61f2,0x411b, 
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0x7c2f,0x0e2c,0x49e0,0xl086,0x5bce,0x5cb7,0x7b56,0x47bd,0x35f3,0x669c > 0x5dl9,0x0fcf,0x4eff,0x421 

d > 0xl7c3,0xll65,0x40b5,0x5042 > 0x5a06,0xl0ad,0x0e07,0xl3bc,0x3770,0x484e,0x2e88 ) 0xl4f9,0x068d ) 0 

X74ff,0x5d54,0x0a53,0x6faf,0x5fd7,0x6b8a,0x27el,0xlbld ) 0x3770,0x38f2,0x071f,0x2ef9,0x62ae,0x32al, 

0x6a7e,0xll65,0x56a9,0x3684,0x372a,0x40c4,0xl50d,0x6a69 ; 0x02ce,0x0caf,0x0e5d,0x329d,0x7b0c,0x2 

513,0x02a8,0x35a9,0x51ec,0x38a8 ) 0xl0ba ) 0x5682,0x594d,0x70bc ) 0x723f,0x5892,0x395c,0x7259,0xldbb 

,0x7f29,0x4da3,0x7d81,0xl9b5,0xl3e6,0x27el > 0x3f9c ) 0x74b2 ) 0x7214,0x0425,0x5401,0x58b9,0x6479 ( 0x 

6fb8,0x7ddb,0x40b5,0x6011,0x5761 ) 0x4529 ) 0x6725,0x7174,0xlf49,0x6d2c,0x4604,0x58f4,0x6725,0x300 

9,0x62df ,0x27el ,0x4dd2,0x392d > 0x7eac,0x7b7d,0x3324,0x 1 de 1 ,0x0779,0x 1 dbb,0x40f8,0x73ad,0x4ea5,0x 

2clc,0x069a,0x6dl0,0xl81b,0x7998 ) 0x462f ) 0x3009,0x47aa ) 0x2241,0x0fcf ) 0x6ca9,0x318c,0x0734,0xlf38 

) 0x6a7e,0x2664,0x4b2e > 0x668b,0x6d2c,0xld87,0x0734,0x519d ) 0x342c ) 0x2980,0x0017 > 0x66b7,0xlecc,0x 

4e99,0x033a,0x2db2,0x4236,0x059c,0x2dc3,0x4487,0x5e08,0x4bl2,0x344a,0x29e6,0x6el6,0x0bea,0x7n 

3,0x3022,0x70e6,0x5ba8,0x0bfd ) 0x0e61,0x7228,0xlb50,0x7ac4,0x4c31,0x0e61 ) 0x29e6,0x2805,0x5e6e,0 

Xlb47,0x531e,0x05ed,0x766b ) 0xl7c3,0xlab3,0x002b,0x6452,0x6e70,0x65fc ) 0x5467,0x7847 ,0x7105,0x2 

150,0x49ad,0x0a53,0x3fb7,0xl488, 

0x5309,0x55b8,0x544c,0x52cl ,0x3 1 fd,0x4398,0x0066,0x3f9c,0x 1 22e,0x 1 7d4,0x32d0,0x097e,0x Ic73,0x2 

C20,0x5416,0x0468,0x090f,0x3d6e,0x3bb9,0x7af8,0xla8f,0x4b39,0x68b0,0x4c6b,0x27bb,0x2dff,0x43fe,0 

X2c51,0x5cb7,0x7b0c,0x01ae,0x73cb,0x2c0b,0x0ce2,0x6dl0,0x4236,0x211d,0x3bdf,0xlef0,0x5024,0xl5 

40,0x36b8,0x2b28,0xlb7b,0x4662,0x6e2a,0x24cc,0x06d7,0x5cdl,0x5a06,0x453e,0x3009,0x6479,0x2562, 

0x5e52,0x77f9,0xl086,0x61bf ) 0xlb50,0x43b3,0x58c8,0x4eb2,0xl56b,0x0e76,0x410c,0xl61c,0xl540,0x4 

0a2,0x4b2e,0x0468,0xl3bc,0x2b28,0xledb,0x6434,0x49ba,0x24e7,0xl0ad,0x6e67,0xlecc,0x4662,0xlc4f, 

0x7c5e,0x0779,Ox24e7,0x3cc0,0x62c8,0x318c,0x61d9,0x35cf,0x3cc0,0x6e5b,0x3ffa,0x7640,0x0bb0,0x28 

39,0xlb6c,0x5ca0,0xlae9,0x345d,0x0432,0x58c8,0x306f,0x3a5a,0x31d6,0x20d5,0x545b,0x4e8e,0x7097, 

0x74ff,0x06bl,0x3ceb,0x4flc,0x6452,0x5966,0x20a4,0x2aad,0x05b7,0x61d9,0xl3da,0x6011,0x3333,0xl 

830,0x4130,0x529b,0xl7fr,0x62c8,0x7b7d,0x6423,0x375b,0x4b63,0x52d6,0x5353,0x6f84,0xl4b4,0x3ca6 

,0x47cc,0x7b7d,0x0bea,0x7537,0xl9c4,0x3022,0xlef0,0x06bl,0x3078,0x6754,0x5e52,0x2629,0x32c7,0x 

1397,0x2980,0x3767,0x02d9,0x0017,0x7163,0x4487,0x6bal,0x669c,0xll03,0x58e3,0x2ec5,0x4515,0x63 

5a,0x592b,0x02f2,0x7eel,0x0425,0x23f8,0x38f2,0x06a6,0x4bl2,0x761a,0x73cb,0x56a9,0x6bec,0x6ccf,0x 

4573,0x4b39,0x6b9d,0x2839,0x604b ( 0x4638,0x4b05,0x217b,0x0el0,0xlf2f,0x0ba7,0x090f,0x51c7,0x301 

e,0x35f3,0x5b94,0x61e5,0x31b0,0x005a,0xl9f8,0x20a4,0x6300,0xlecc,0x5d0e,0xll3f,0x66fa,0x23f8,0x5 

018,0x748e,0x593c,0x6922,0x239e,0x5c9c,0x5885,0x2b65,0x394b,0x66dl,0x4991,0x4b39,0x0e61,0xl67 

a,0x2eb4,0x4613,0x4828,0x4ec3,0x6194,0xl9f8,0x2eee,0x43b3,0x6743,0x3bf4,0x787b,0x2eb4,0xlee7,0x 

4127,0x0e4a,0xl99e,0x7139,0x767c,0x6452,0x632b,0x7c38,0x5467,0x2b4e,0xl4d2,0x74c3,0x6a69,0x23 

9e,0x51fb,0x56cf,0x3767,0x51c7,0x2863,0x31a7,0x2e88,0x5707,0xl3ab,0x2673,0x0bd6,0x633c,0x0192, 

0x528c,0x677f,0x392d > 0x2538,0x6725,0x2098,0x6935,0x3461,0x2227,0x3701,0x6183,0xll3f,0x23a2,0x 

7f64,0x3a00,0x5033,0x40ef,0x5c9c,0x372a,0x798f,0x4aab,0x3fa0,0x239e,0x6a7e,0x760d,0x2d99,0x5d68, 

0x35cf,0x786c,0xl57c,0x4130,0x3716, 

0x5fc0,0x0752,0x29e6,0x285f,0x20e9,0x7097,0x6bc7,0x068d,0xlad5,0x7c2f,0x47f0,0x2874,0x4141,0x6 

6ed,0xlf62,0x55f5,0x40c4,0x2b03,0x2db2,0x5e08,0xld90,0x7112,0x62f4,0x36de,0x7f3e,0x2eee,0x6fde,0 

X751c,0x3el9,0x5966,0x23b5,0x6d5d,0x3al7,0x0fa9,0xlad5,0x0ff3,0x5cb7,0xl086,0x2c37,0xl7a5,0x42 

21,0x02d9,0xld90,0x3701,0x77a3,0x3716,0x3d79,0x7ab5,0x7aa2,0xlc73,0x40d3,0x0942,0xlb50,0x2504, 

0x2c37,0x4dc5,0x5776,0x6c95,0x659a,0xlad5,0x3f8b,0x756d,0x5e6e,0x7203,0x5feb,0x208f,0x3al7,0xla 

d5,0x5d68,0x2812,0x227d,0x3009,0x6953,0x0745,0x3078,0x059c,0x43b3,0x55e2,0x3cd7,0x3f8b,0x0ale, 

0x2f26,0xl274,0x0cf5,0x227d,0x4aab,0xlecc,0x7821,0x4ee8,0x79b3,0x2de8,0x689b,0x05b7,0x484e,0x6 

70e,0x342c,0xl7c3,0x005a,0x4db4,0x27bb,0x7b41,0x66c6,0xlab3,0x4d9f,0x2658,0x342c,0xl49f,0x0d01 

,0x531e,0x3e0e,0x08ec,0x2d8e,0x58df,0x3d52,0x43e9,0x56be,0x2c0b,0x5a5c,0x52b0,0x760d,0x3a00,0x4 

b74,0x02a8,0x6366,0x7dbd,0xle96,0xl3cd,0x5b83,0xl7a5,0x798f,0x3el9,0xl50d,0x7eca,0x61a8,0x4d88 

,0x52b0,0xl9a2,0x2dff,0x61f2,0x70ab,0x47db,0x0a78,0x0d2a,(jxl248,0xle81,0x65c0,0x453e,0x3977,0x7 

546,0x62df,0x7dbd,0x4558,0x2ef9,0xl66d,0x02d9,0x0caf,0x08c7,0xlc29,0x7d96,0x7626,0x0185,0x3333, 

0x5bd9,0x 1 1 3f ,Ox604b,0xlc29,0x27dd,0x5d0e,Ox3333,0x6fe2,0x7 105,0x 1 b6c,0x6bal ,0x6a55,0x0 1 df,0x7 

9fe,0x32d0,0x5055,0x4564,0x4f37,0x2fla,0x31ea,0x4221,0xlfl3,0x7dfl),0x5be5,0x2874,0x68cl,0x483f,0 

X0454,0x0a6f,0x4564,0xl4a3,0x572c,0x6423,0x7551,0x79e9,0x31d6,0x6bec,0x5d68,0x55c9,0x2c51,0x04 

54,0x0f95,0xl9c4,0x781d,0x047f,0x4ae6,0xl488,0x2f31,0x411b,0x4a97,0x6a0f,0x52ea,0x040e,0x23ef,0x 
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542a,0xll03,0x0ale,0x6a42,0x3333,0xlb0a,0x5470,0x3582,0x536f,0x4515,0x5a2d,0x7ad3,0x70cd,0xll2 
8,0xle81,0x264f,0x02ce,0x6300,0x6ff5,0x52a7,0x034b,0x410c,0x7dbd,0x5a77,0x0a22,0x01f4,0x035c,0x 
4865,0x6c82,0x7998,0x0d01,0x345d,0x6e2a,0x7850,0x040e,0x6c95,0x0c84,0x3883,0x5042,0x6e4c,0xlb 
7b,0x7163,0x38bf,0x47db,0x35e4,0x574a,0x4acd,0x27ac,0x7850,0xl380,0x2136,0xlb6c,0x6e67,0x301e ) 
0x7 148,0x40b5,0x5a5c,0x6bd0,0x lebd,0x66d 1 ,0x24f0,0x6a69,0x2f6b,0x2787,0x4b 1 2,0x52ea,0x68ea,0x2 
790,0xlf62,0x263e,0x3883,0xl49f, 

0x7847 ,0x70da,0x220c,0x4c57,0x0f95,0x4abc,0x033a,0x4558,0x787b,0x61a8,0x4f51,0x31fd,0x3fdl,0x24 

e7,0x4247,0x08b6,0x4f0b,0x0185,0xl380,0x24aa,0xl212,0x3a3c,0xlaa4,0x536f,0x29cd,0x3461,0x0745,0 

x36e2,0x4f20,0x47db,0x370 1 ,0x4ec3,0x3e54,0xl ab3,0x4490,0x2790,0x2aba,0x3bf4,0x2O 1 ,0x44e 1 ,0x65f 

C,0x7f73 5 0x5776,0x216c,0xlddd,0x27f6,0x2538,0x058b,0x634d,0x0468,0x4865,0x542a,0x52d6 i 0x36b8,0 

X2602,0x689b,0x2098,0x35e4,0xlb47,0x2c6d,0x7c75,0x2c7a,0x58b9,0x36de,0xl248,0x2839,0x0000,0x6 

34d,0x5a3a,0x70fl,0x56be,0x66a0,0x70fl,0x047f,0x7105,0x43e9,0x20a4,0x20b3,0x4859,0xl4d2,0x767c, 

0x35be,0x3fed,0x If5e,0x45 1 5,0x5024,0x38e5,0x3ffa,0x 1 84 1 ,0x44bb,0x 1 b7b,0x003c,0x4ec3,0x4 1 1 b,0x33 

24,0x3078,0x0a22,0x66fa,0x02d9 j 0x4ae6,0x08al,0x0377,0x29cd,0x35be,0x5695,0x7blb,0x01e3,0x49f7,0 

X0a78,0x417d,0x36f5,0x0d3d,0x3355,0x65c0,0x761a,0x5ced,0x0e76,0x2513,0x01e3,0x3693,0x507e,0x09 

69,0x7631,0x56e4,0xlc64,0x217b,0x08b6,0x5033,0x0d67,0xlf49,0x724e,0x545b,0x6al8,0x040e,0x77d2, 

0x0924,0x7f64,0x6bd0,0x7c62,0x090f,0x4dd2,0x2f3 1 ,0x5d43,0x3d08,0x5be5,0x5al 1 ,0x4c3 1 ,0x43e9,0x3 

Ifd,0x3fa0,0x6c95,0x4662,0x544c,0x5cb7,0x6d4a,0x6e2a,0x0b9b,0x61f2,0x52cl,0x49cb,0x08b6,0x0306, 

0x5d25,0x659a,0x6292,0x5fa6,0x6bal,0x56O,0xl205,0x5401,0x65 

9a2,0x62ae,0x2d8e,0x79fe,0xlc58,0x2615,0x602d,0x3053,0x7dcc,0x36c9,0x7850,0x2997,0x4796,0x691e 

,0x6faf,0x77ee,0x01ae,0x409e,0x0419,0x29bc,0x3a5a,0x5dl9,0x49e0,0xl0f7,0x0a09,0x62e3,0x5bd9,0x6 

e2a,0x2121,0xlb50,0x5fa6,0x0969,0x4bl2,0xlb7b,0x7c04,0x756d ) 0x6b8a,0x4156,0x7d81,0x31d6,0x4e9 

9,0x79a4,0x4d88,0x3e43,0x2241,0x7265,0x68cl,0x040e,0x5335,0x0bcl,0x0723,0x3770,0x2aad,0x5elf,0. 

X748e,0x7788,0xlf75,0x3fc6,0x5e23,0x6e3d,0x0b8c,0x38ce,0x0377,0xl60b,0x5055,0x723f,0xl0dc,0x02 

d9,0xl61c,0x70bc,0x4f51,0xlc58,0x7520,0x670e,0x55c9,0x5e34,0x3fa0,0xll72,0x6c82,0x500f,0x5b94,0 

X20d5,0x438f,0x65a6,0xl49f,0x4221,0x7b0c,0x7b6a,0x4b39,0x3410,0x0734 > 0x29da,0x4c40,0x47bd,0x51 

d0,0x0e76,0x5695,0x3 19b,0x4ada,0x5966,0x7eel ,0x 1 ac2,0x5 1 9d,0x4db4,0x500f,0x7f4f, 0x499 1 ,0x33 1 8,0 

x7b7d,0x004d,0x 1 488,0x7 1 39,0x7daa, 

0x3d6e,0x02ce,0x5fc0,0x2eb4,0x5d43,0x7259,0x6bc7,0x6909,0xl488,0x61f2,0x5e08,0x7998,0x0bb0,0x4 
e8e,0xl856,0x3e43,0x4221,0x2980,0x2848,0x668b,0x545b,0xlb50,0x068d,0x5710,0x4398,0x56f3,0x5cc 
6,0x49f7,0x62ae,0x49ad,0x27ac,0x344a,0x7847,0x43b3,0x68d6,0x4b63,0xl67a,0x5761,0x5e52,0x6e3d,0 
X79d5,0x6c82,0x6445,0x2481,0x2997,0x6408,0x756d,0x0779,0xlab3,0x74d4,0x6317,0x343b,0x6fc9,0xl 
ac2,0x0443 ,0x 1 ef0,0x3fc6,0x6732,0x2c7a,0x 1 3f 1 ,0x4859,0x02a8 ,0x337e,0x5d7f ,0x 1 57c,0x 1 b2 1 ,0x56a9, 
0xll59,0x29fl,0x05c6,0x6719,0x337e,0x328a,0x31cl,0x30 

9a,0xl212,0xll28,0xl66d,0x3e43,0x3d79,0x6bc7,0x2c7a,0x4250,0x2c20,0x6bfb,0x5776,0x484e,0x3894^ 

Ox 1 827 ,0x43fe,0x 1 c3e,0x01 b9,0x 1 87d,0x6366,0x54 1 6,0x2b 1 4,0x74e8,0x6a 1 8,0x3 1 a7,0x55c9,0x 1 84 1 ,0x4 

26c,0x688c,0x2dc3,0x4221,0x6d07,0x4649,0x3fc6,0x4564,0x0b8c,0xl239,0xll03,0x6bfb,0x4c7c,0x5584 

,0x2805,0x6d2c,0x32al,0x6011,0x3al7,0x634d,0xlab3,0x3fed,0x02e5,0x0d67,0x0bea,0x3595,0x2658,0x 

Ic3e,0x35cf,0x3369,0x227d,0x4c26,0x65c0,0x090f,0x2a86,0x5917,0x033a,0x421d,0x0c93,0x4a80,0x093 

3,0x0a09,0x688c,0xl637,0x5b83,0x760d,0x38f2,0x0ff3,0xl380,0x5033,0x5d25,0x7f58,0x3461,0x3cfc,0x 

1557,0x05ed,0x005a,0x29fl,0x4ada,0xlee7,0x7546,0x2fla,0xla98,0x572c,0x31b0,0x2602,0x52b0,0xl7a 

5,0x4564,0x78 Id,0x02d9,0x4b63,0x3e0e,0x6445,0x3bc8,0x56be,0x03 1 1 ,0x6ce4,0x2389,0x3044,0x36de,0 

X6935,0x2787,0x593c,0xlc4f,0x3d6e,0x417d,0xl651,0x0066,0x44dd,0x4a97,0x6a69,0x6f93,0x49f7,0x02 

94,0x29cd,0x483f,0xl620,0x7788,0x6cf3,0x4490,0x5069,0xl086,0xl3fl,0x0425,0x3cfc,0x6423,0x6a0f,0 

X4eb2,0x032d,0x0d67,0xlf49,0x5892,0x5a4b,0x6452,0x543d,0x005a,0x090f,0xl78e,0x3be3,0x44el,0xl5 

7c,0x602d,0x483f,0x0d01,0x0283,0x02f2,0x4b39,0x5feb,0x32d0,0x6cd8,0x3fed,0x7de7,0x696f,0x343b,0 

X7c49,0x4eff,0x0443,0x5all,0x5761,0x4b5f,0x374 

30,0xl57c,0x55e2,0x6292,0x3693,0x6a42,0x2839,0x465e,0x3b92,0x5d25,0x3a00,0x38e5,0x65fc,0x7c2f,0 
Xl557,0xl4c5,0x0360,0x32d0,0x62b9,0x6a0f,0xl397,0x4141,0x68d6,0xl827,0xl526,0xlb47,0x2b28,0x2 
8 1 2,0x3 1 b0,0x3c9a,0x 1 7e8 ,0x 1 8 1 b,Ox3be3 , 
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0xlc64,0x6bc7,0xlc73,0x55e2,0x4613,0x3342,0x392d,0x44f6,0xl50d,0x318c,0x4f0b,0x3318,0xl81b,0xl 
0e0,0x3d6e,0x44ac,0x6al8,0x343b,0x4c26,0x221b,0x6408,0x4613,0x47bd,0x3d45,0x4127,0x27bb,0x306 
f,0x23d3,0xl7e8,0x4ae6,0x3e68,0x44el,0x373d,0x0b^ 

4502,0x7fl5,0x36af,0x2f26,0x38bf,0x7228,0x4b74,0x5bd9,0x0192,0x7ddb,0x0d5b,0x605c,0x7ddb,0x239 

e,0x239e,0x52a7 ) 0x7112,0x5elf,0x4c6b,0x7836 J 0x4df9,Ox7499,Ox02e5,0x3911 5 0x0cb8,Ox70fl,0x3e32,0x 

4e8e,0x7aef,0x6768,0xl7e8,0x7daa,0x6ce4,0x3770,0x4a97,0x05fa,0x68fd,0x70da,0x2f0d,0x5470,0x7259, 

0x3b85,0x318c,0x3022,0x5c9c,0x210a,0x033a,0x7203,0x77a3,0x4a97,0x7272,0x56be,0x7daa,0x0e3b,0x4 

3c2,0x62f4,0x70ab,0x43d5,0x2256,0x73dc,0x0d 1 6,0x52c 1 ,0x5335,0x40 c,0x252f , 0x5 8e3 ,0x6fe2,0x6bfb, 

0x3410,0x4c40,0x7c04,0x5ba8,0x306f,0x0e07,0x36b8,0x2f40,0x395c,0x465e,0x55af,0x2dc3,0x44bb,0x0 

723,0x4b05,0x4aab,0x6ccf,0xlb6c,0x5593,0x0d5b,0x0cb8,0xl81b,0x3fc6,0x7ab5,0x68fd,0x79e9,0x2ec5, 

0x5900,0x6060,0x575d,0x47cc,0x5e6e,0x02e5,0x7c75,0x2256,0x20d5,0x2d99,0x518a,0x4db4,0x6a42,0x 

330f,0x641f,0x0454,0x3bf4,0x375b,0x77a3,0x08ec,0x27dd,0x7aef,0x712e,0x6fde,0x0955,0x7blb,0x2f0^ 

0x55b8,0x285f,0x6194,0x5e45,0x2f40,0x0dl6,0x51ec,0xl3ab,0x06c0,0x7fl5,0x65c0,0x5707,0x3b85,0x0 

306,0x3770,0x3693,0x6ce4,0x7836,0x2ef9,0x6e4c,0x70ab,0x5fbl,0x43fe,0x70e6,0x372a,0x2812,0xlc58, 

0x575d,0x7d96,0x05fa,0x58e3,0x5ffc,0x43c2,0x27ac,0xl9f8,0x0cc9,0xlafe,0x2147,0x7ddb,0x36c9,0xl4 

88,0x392d,0x6d5d,0x20d5 ,0x7daa,0x484e,0x27bb,0x3767 ,0x595a,0x4 1 0c,0x2538,0x4b74,0x5593 ,0x2 1 0a, 

0x0d2a,0x 1 799,0x6fe2,0x38f 2,0x757a,0x0caf ,0x4df9,0x7520,0x3fc6,0x076e,0x 1 f75 ,0x 1 edb,0x 1 49f ,0x20e 

9,0xl0ba,0x7f58,0x798f,0x2f26,0x7272,0x4c40,0x55af,0x2ef9,0x0cf5,0x2b65,0x70fl,0x7112,0x0dl6,0x5 

ba8,0x0c93,0x0b8c,0x2227,0x7228,0x01df,0x6434,0x7daa,0x2an,0x319b,0x306f,0x2615,0x6e4c,0x55af, 

0x58df,0x3035,0x7f3e,0x3bf4,0x5e52,0x519d,0x4aab,0x79b3,0x3e32,0x3324,0x465e,0xleaa,0xldf6,0x59 

5a,0x44bb,0x3333,0x2256,0x2147,0x4da3,0x0cc9,0x239e,0x02f2,0x2b03,0x2f40,0x79b3,0xldel,0x5335, 

0x6d2c,0x5966,0x7203,0x748e, 

0x06b 1 ,0x6732,0x06d7,0x574a,0x 1 274,0x2f 0d,0x3022,0x4ae6,0x3d52,0x68c 1 ,0x4573 ,0x3fdl ,0x0377,0x5 

6be,0x0d4c,0x52ea,0x5c9c,0x40f8,0x5353,0x4c0d,0x4156,0x3c9a,0x4a97,0xl248,0x438f,0x7203,0x5018, 

0x4141,0x66fa,0x4573,0x3b85,0xlc02,0x24db,0x0bea,0x5e52,0x20fe,0x2227,0x395c,0x47f0,0xlb50,0x5 

5e2,0x040e,0x52c 1 ,0x040e,0x0468 ,0x757a,0x6bfb,0x2f26,0x 1 830,0x7 1 63 ,0x 1 989,0x540 1 ,0x226a,0x5a06 

,0x0e07,0x426c,0x43d5,0x3595,0x32ec,0x3e7f,0xl7b2,0x3f9c,0x3f8b,0x61d9,0x2c51,0x787b,0x6b8a,0x5 

917,0x6300,0x61e5 i 0x6445,0x373d,0xlaa4,0x2c20,0xll28,0x0c93,0x36af,0x536f,0x31d6,0x4dee 5 0x5 

0x7c75,0x0a35,0x5ced,0x3a00,0x4649,0x2af7,0x2839,0x47db,0x3a4d,0x2b65,0x70ab,0x034b,0x097e,0x6 

d07,0x 1 7d4,0x6c95 ,0x544c,0x6 1 94,0x27dd,0x05d 1 ,0x 1 aa4,0x62e3 ,0x0 1 ae,0x7af8,0x5069,0x2acb,0x7b7d 

,0x49e0,0x6a69,0x23a2,0xlll4,0xlaa4,0x2b72,0x574a,0x282e,0x3d08,0xl397,0x7626,0x08c7,0x06c0,0x 

7097,0x217b,0x58c8,0x4abc,0x0ff3,0x62df,0x4c26,0x5900,0x3cc0,0x20e9,0x688c,0x6452,0x6ce4,0x7f73 

,0x0ale,0x2acb,0xl830,0xlc4f,0x3977,0x44el,0x779f,0x7f4f,0x3bb9,0x4638,0x49f7,0xl9b5,0x2ea3,^^ 

4e,0x7f58,0x6faf,0x05a0,0x5353,0x06a6,0x6754,0x68cl,0x0a78,0x32ec,0x2549,0x6a24,0xll59,0x2eb4,0 

X05c6,0x3e43,0x0933,0x52d6,0x74a5,0x08b6,0x4558,0x7c62,0x301e,0x781d,0x4c57,0x0066,0x27el,0x3 

C9a,0x2673,0x32b6,0x4e99,0x760d,0x4b63,0x4675,0x2575,0x658d,0x0933,0x4acd,0x4c0d,0x7214,0x7da 

a,0x5584,0x2e88,0x217b,0xl540,0x393a,0xlaa4,0xld87,0x4ae6,0xlbld,0x65fc,0x089d,0x20a4,0x5c8b,0 

X3e68,0x7b30,0x61a8,0x66ed,0xl620,0x5695,0x56cf,0x4b48,0x3324,0xl3ab,0x66a0,0x01df,0x56e4,0x70 

e6,0x7af8,0x5593,0x3009,0x5695,0x5fa6,0x3684,0x73e0,0xl9c4,0x7836,0xle81,0x31d6,0x02e5,0x2b72, 

0x427b,0x40ef,0x35f3,0xl51a,0x345d,0xlll4,0x01ae,0x4558,0x6909,0x781d,0x66c6,0x6011,0x3022,0xl 

4d2,0x43 8f ,0x3d34,0x7de7,0x6 1 94,0x0a35,0x3bb9,0x 1 84 1 ,0x3a66,0x2c37,0x 1 ae9,0x0al e,0x27e 1 ,0x394b 

,0x61a8,0x531e,0xl7d4,0x65fc,0xl61c,0x047f,0xl526,0x7e90,0x059c,0x4573,0xl380,0x5a2d,0x5e45,0x2 

52f,0x6e3d,0x374c,0x6al8,0x65eb,0xlc3e,0x3342,0x5707,0x74e8,0x6e3d,0x06c0,0x7631,0x38e5,0x31cl, 

0x1 830,0x5024,0x3bdf,0x5470,0x4abc, 

0x2ec5,0x6a69,0x528c,0x06d7,0x3bae,0x0066,0x49e0,0x4b2e,0xll65,0x5707,0x2eee,0x27ca,0x68b0,0x0 

89d,0x594d,0x3d34,0x52b0,0xlb36,0x65eb,0x4acd,0x3fed,0xl0dc,0xl22e,0x38e5,0x7f3e,0x65c0,0x65bl, 

0x4604,0xl248,0x5all,0x5707,0x5344,0x62b9,0xl4ee,0x7499,0x7551,0x4515,0xl4d2,0x3e0e,0x38ce,0x 

2c20,0x034b,Ox2863,0xle81,0x337e,Ox217b,0x2496,0x0443,0x24e7,0xO432,0x375b,0x38e5,0x36de,0x54 

67,0x216c,0xl091,0x3bc8,0x7ef6,0x36de,0x06c0,0x65c0,0x6a0f,0x633c,0x24e7,0x4781,0xl3cd,0x74c3,0 

X5353,0x4c31,0x61bf,0x3f9c,0x0cb8,0x3767,0x282e,0x7850,0x2664,0x5feb,0x2c7a,0x484e,0xlac2,0x20f 

e,0x 1 c02,0x65fc,0x 1 d90,0x 1 7a5,0x6300,0x0294,0x7e90,0x5 1 9d,0x43fe,0x5892,0x763 1 ,0x4b74,0x20b3,0 

X3369,0x3022,0x47bd,0x0bb0,0xl488,0x6bc7,0x44dd,0x40a2,0x4da3,0x61a8,0xl66d,0x5d54,0x5bce,0x4 
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859,0x003c,0x5069,0x4f20,0x6 1 f2,0x62b9,0x3e7f ,0x 1 c29,0x6a69,0x49cb,0x 1 e8 1 ,0x59 1 7,0x5042,0x2098, 

0x3a3c,0xlb47,0x5d32,0x70da,0x4613,0x5c8b,0x2673,0x3e43,0x6e4c,0x595a,0x3684,0x0933,0x73cb,0x 

7(kd,0x7b7d,0x7788,0x2664,0x7eel,0x0b9b,0x7e90,0x3^ 

,0x61f2,0x43a4,0xlb21,0x40f8,0x068d,0x43b3,0x35d8,0x3d6e,0x79d5,0xldbb,0xll28,0x5042,0x090f,0x 

65a6,0x5d0e,0x2c5 1 ,0x426c,0x4 1 30,0x43e9,0x7788,0x003c,0x499 1 ,0x2790,0x6fe2,0x47f0,0x3 1 b0,0x70c 

d,0x05ed,0x344a,0x337e,0xldel,0x7163,0x3b85,0x7998,0x52b0,0xlad5,0x2227,0x23a2,0x43b3,0xl9ef,0 

X3bc8,0x3960,0xlc4f,0x058b,0x5d0e,0x29ab,0x0ba7,0x2clc,0x4c7c,0x5d25,0x6292,0x5a2d,0x5055,0x29 

da,0x5e79,0x3078,0x239e,0x2ef9,0x0e3b,0x342c,0x66dl,0x5e79,0x7de7,0xlc73,0x3977,0x2fla,0x36de,0 

X7174,0x3cbl,0x0ff3,0x751c,0x52b0,0x6cd8,0x49f7,0x605c,0x56be,0x7105,0x61bf,0x5be5,0x6408,0x46 

75,0xl3cd,0x227d,0xl87d,0xl3cd,0x65a6,0x688c,0xl09^ 

0x4991,0x5f9a,0x411b,0x5a3a,0x32c7,0x0bfd,0x5055,0x4f46,0x23b5,0x01b9,0x2848,0x65a6,0x2790,0x0 
2f2,0xl4f9,0x23f8,0x02e5,0x73e0,0x0933,0x670e,0x239e,0xl3cd,0x427b,0x27el,0x3078,0x2c20,0x6d61, 
0xlab3,0xl80c,0x0360,0x6a7e,0x2496,0x31fd,0x68ea,0x4859,0x0f82,0x454f,0x5bf2,0x29cd,0x65eb,0x77 
9f,0xldel,0x6011,0x263e,0x691e,0x5033, 

0x756d,0x2664,0x658d,0x0bea,0x5dl9,0x5a4b,0x02d9,0x74d4,0x4b48,0x32d0,0x66ed,0x417d,0x6408,0x 
345d,0x4b5f,0xl0ba,0x77ee,0x47e7,0x4d9f,0x5e08,0x543d,0xldca,0x040e,0x374c,0x27dd,0xl9ef,0x453e 
,0xl263,0x0468,0x6bd0,0x594d,0x633c,0x0ff3,0x0a22,0x6a69,0x2098,0x52cl,0x3fa0,0x2d8e,0x66fa,0x0 
04d,0x6bal,0x4afl,0x49ad,0x4ada,0x52b0,0x0d2a,0x27ca,0x23f8,0x5fd7,0x4ada,0x669c,0x0071 5 0x61f2,0 
x7265,0x49ad,0xl87d,0x47aa,0x6al8,0xl4M,0x20e9,0x62f4,0x500f,0xl212,0x49cb,0x2602,0x575d,0x3d 
6e,0x3bf4,0x4d9f,0x2538,0x52cl,0x6909,0x70da 5 0xldel,0x2b72,0x4c0d,0x420a,0x2602,0x669c,0xl86a,0 
X24f0,0xl50d,0x0a53,0xl841,0x6bfb,0xlb21,0x23a2,0x5d7f,0x2562,0x3d52,0x0fa9,0xl9c4,0x5966,0x0fc 
f,0x3883,0x4c57,0xl0cb,0x4f20,0x090f,0x3355,0x0b9b,0x411b,0x2389,0x328a,0x2c0b,0x0942,0x395c,0x 
0f82,0x5966,0xl0cb,0xl989,0x7fl5,0x5b94,0xlafe,0x^ 

Ox 1 Iff fix 1 dbb,0x2f 1 a,0x6d3b,0x2a86,0x7d8 1 ,0x2ed2,0x7 1 05,0x0fcf ,0x2ec5,0x3 37e,0x4f0b,0x5 8df,0x238 

9,0x090f,0x36f5,0xledb,0x4796,0x3e25,0x0e61,0xl9ef,0xlbld,0x7f02,0x6183,0x7148,0x574a,0x62c8,0x 

034b,0x4abc,0x4ae6,0x73cb,0x7080,0x61ce,0xin5,0x40b5,0x4abc,0x58e3,0x373d,0x4f7a,0x6a7e,0xl4d2 

,0x 1 dca,0x4c 1 a,0x0caf ,0x0432,0x0ce2,0x0cde,0x44bb,0x 1 f62,0x059c,0x 1 e96,0x5e52,0x0cf5 ,0x7de7,0x63 

17,0x7b27,0x6ca9,0x5344,0x6d76,0x2b72,0x47aa,0x38e5,0x2c0b,0x29ab,0x7eca,0x0311,0x7fl5,0x3fb7,0 

X0066,0x3e68,0x0a35,0x5e34,0x7836,0x780a,0x3407,0x343b,0xl212,0x2812,0x2f7c,0x3e68,0x6f84,0x73 

86,0x49ad,0x767c,0x5bce,0x3f9c,0x 1 14e,0x5344,0x7b 1 b,0x70e6,0x0a09,0x5d32,0x0468,0x 1 9f 8,0x79d5,0 

X0955,0x79b3,0x5bf2,0xlb36,0x7626,0x3333,0x4865,0x097e,0x6285,0x255e,0x3d52,0x31a7,0x7de7,0x7 

c75,0x78 1 d,0x2 1 0a,0x5 1 8a,0x4df9,0x05d 1 ,0x7d96,0x3 1 9b,0x5d68 ,0x 1 a98,0x 1 afe,0x4 1 30,0x0fe4,0x669c, 

0x2504,0x35e4,0x6c95,0x02a8,0x394b,0x5e34,0x3a2b,0x5e6e,0x4487,0x3d52,0xl4d2,0xll59,0x5322,0x 

7112,0xl3ab,0x32al,0x4564 > 0xl526,0x68ea,0x6faf,0x2eee,0x7eac,0x35be,0x318c,0x0425,0x7blb,0xl397 

,0x6d6 1 ,0x2c20,0x5 1 fb,0x3e 1 9,0x3c9a,0x227d,0x226a,0x3ca6,0x646e,0x5 1 8a,0x2098 ,0x4c40,0x5e08 ,0x 1 

557,0x06d7,0x55b8,0x02d9, 

0x7a89,0x528c,0x7836,0x0a22,0x2c37,0xla98,0x7b30,0x047f,0x392d,0x3911,0x35cf,0x27dd,0x35f3,0xl 

557,0x6bb6,0xl557,0x2ae0,0x06c0,0x6371,0x6a69,0x4df9,0x68b0,0x4c26,0x047f,0x5353,0x417d,0x5971 

,0x5dl9,0x2aad,0x4558,0x0a35,0x4b05,0x5cb7,0xl637,0xll03,0x0443,0x23b5,0xl57c,0x7eac,0x6ca9,0x 

Idel,0x3fdl,0x4828,0x5ca0,0x62f4,0x071f,0x66ed,0x20b3,0x5d54,0x5900,0x3el9,0x01df,0x7821,0x7c6 

2,0x6bal,0x43c2,0x3e25,0x595a,0x033a,0x372a,0x5042,0x6077,0x2504,0x0ff3,0x6ca9,0x55b8,0x604b,0x 

005a,0x0443,0x2863,0x5710,0xlae9,0x38f2,0x4bl2,0x766b,0x01f4,0x3684,0x0454,0xll72,0x29da,0x0be 

a, 0x2e88,0xl4c5,0x7b30,0x4991,0x375b,0x4c31,0x2839,0x2664,0x06fc,0x7c49,0xldca,0x2658,0x035c,0 
X5dl9,0x7aa2,0x40f8,0x24f0,0x2acb,0x4acd,0x786c,0x32ec,0x56f3,0xl263,0x6a69,0x3582,0x4ec3,0x4aa 

b, 0x7c38,0xlc58,0x4ec3,0x06a6,0x0a22,0x3324,0x7d81,0x7c49,0xl3da,0x595a,0x342c,0x786c,0x4859,0 
x5055 ,0x 1 de 1 ,0x6a24,0x6909,0x0ff 3,0x4f20,0x30 1 e,0x 1 84 1 ,0x285f ,0x670e,0x 1 65 1 , Ox 1 66d,0x36c9,0x59 
2b,0xlc73,0x4828,0x2787,0x484e,0x44ac,0x23a2,0x70bc,0x6d07,0xl67a,0xl67a,0x43d5,0xlae9,0x58e3, 
0xl7e8,0x3bf4,0x3d79,0x20e9,0x282e,0x040e,0x4127,0x2658,0x5d25,0x2aba,0x2c6d,0x24e7,0x74e8,0x5 
6e4,0xl87d,0x05b7,0x3318,0x38d9,0x483f,0x44bb,0x2b03,0x05fa,0x7ebb,0x2629,0xl78e,0x285f,0x6f93, 
0x4flc,0x6445,0x4127,0xldca,0x5f9a,0x0d3d,0x4529,0x36c9,0x4649,0x43fe,0x6faf,0x4na,0x4flc,0x7f3 
e,0x0306,0x4649,0x462f,0xl 9a2,0x3407,0x3 894,0x45 29,0x3f8b,0x 1 22e,0x3693,0x 1 e81 ,0x0a09,0x03 1 1 ,0 
X760d,0x453e,0x766b,0x62e3,0x47f0,0x5892,0x409e,0x5cdl,0x3342,0xl3da,0x66dl,0x3b92,0x7c75,0x6 
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434,0x68fd,0xl7c3,0x5a2d,0x05dl,0x227d,0x36f5 ) 0x5f9a,0x7ebb,0x208f,0x285f,0x36f5,0x7e87,0xl856,0 
x632b,0x6445,0x6944,0xlbld,0xl397,0x08al,0x05dl,0x6f93,0xl80^ 

6c,0x08ec,0x2b03,0x034b,0x4236,0x0a35,0x3fb7,0x3fa0,0x7640,0x6445,0x4b63,0xl263,0x392d,0x56d8, 
0xl380,0x4dc5,0x2eb4,0x392d,0x4afl,0x77d2,0x0e3b,0x3cd7,0x24db,0x62e3,0xl4a3,0xl274,0xl3da ) 0xl 
b36,0xlf62,0x38a8,0x2f40,0xl651,0x2b59,0x58f4,0x4c57,0x58 
0x4221,0x409e,0x5917,0x2602,0x7c49, 

0x08al,0x3a2b,0x7f4f,0x6c82,0x0d67,0x3dlf,0x05b7,0x2^ 

752,0xlc4f,0x6768,0x646e,0x4675,0x7265,0x3fed > 0x62f4,0x688c,0x20fe,0x51al,0x5966,0x6b8a,0x31d6, 

0xlef0,0x7eca,0x2b3f,0x4247,0x4df9,0x7520,0x0ce2,0x5a3a,0x7edd,0x2c37,0x097e,0x4ada,0x2ae0 5 0xld 

f6,0x545b,0x2f31,0x3906,0x47aa,0x4250 5 0x6292,0x5d7f,0xl091,0x68fd,0xl799,0x374c,0x4ae6,0x004d,0 

x6978,0x603a,0x329d,0x7cl3 > 0x4ee8,0xl78e,0x2513,0x23b5,0x0bfd,0x66fa 5 0x454f,0x712e,0xl3da,0xH 

9f,0xl57c,0x2575 ) 0x0caf,0x7af8,0x6dl0,0x5fd7,0xlbld,0x4236,0x73ad,0x4b48,0x79a4,0x7499,0x6b9d,0 

X217b,0x033a,0xl9d3,0x2241,0x5e45,0x5d54,0x4529 5 0x2805,0x2504,0x3684,0xlae9,0x0bcl,0x51al,0x6 

317,0x0d2a,0x4e8e,0x58ae,0x7aa2,0x301e,0x2eee,0x4803,0x5710,0x31a7,0x3d52,0x659a,0x3be3,0x7265, 

0x4b5f,0x40d3,0x66ed,0x4db4,0x7f73,0x410c,0x77f9,0xl989,0x23ef,0x787b,0x49cb,0x4d9f,0x05fa,0x2e 

b4,0xl239,0x6944,0xl4ee,0x0066,0xldac,0xl3bc,0x2da5,0x0fcf,0x0071,0x7ddb,0x6fe2 5 0x5b94,0x798f,0 

X0745,0x44el,0x4872,0x06d7,0x7edd,0x0c84,0x417d,0xlee7,0x3701,0x23c4,0x4b2e,0x0cc9,0x38e5,0x38 

bf,0x3684,0x3el9,0x65fc,0x7dfi0,0x0fd8,0x7105,0xl^^ 

059c,0xl4f9,0xl4c5,0x0d5b,0x0918,0x3960,0xl830,0x68a7,0x751c,0x5707,0xlb47,0x52b0,0x4490,0x31 

ea,0x6f84,0x6e4c,0x4613,0xl620,0xl248,0x4604,0x70fl,0xl0ad,0x44bb,0x4247,0x65d7,0x51b6,0x24cc^ 

0x6935,0x0734,0x7b56,0x43c2,0x4796,0x7640,0x5042,0x5bd9,0x2513,0x2ed2,0x2b59,0x0942,0x2629,0x 

635a,0x2b28,0x374c,0x36f5,0x2eb4,0xl0dc,0x3bc8,0xlc73,0x210a,0xla8f,0x032d,0x02a8,0x6a24,0x24a 

a,0x0bd6,0x36af,0x3a2b,0x51c7,0x79c2,0x4db4,0x5401 > 0x74a5,0x05fa,0x2c0b > 0x6452,0x6el6,0x438f,0x 

151a,0x2af7,0x6bb6,0x0c93,0x507e,0xl488,0x0ale,0x3e0e,0x7daa,0x6719,0x2658,0xlc64 > 0x0294,0x6e 

d,0x3053,0xl526,0x61a8,0xl80c,0x5fa6,0x0ale,0x4da3,0x4c7c,0x7f4f,0x6719,0x43d5,0x7139,0x4f37,0x 

2980,0x08d0,0x79b3,0x4662,0x3cbl,0x0a22,0x3053,0x24db,0x56a9,0x500f,0x536f,0x58f4,0xl239,0x55e 

2,0x74ff,0x6ccf,0x2241,0x66fa,0xl531,0x5a5c,0x5344,0xin5 5 0x2c6d,0x5584,0x5917,0xla98,0x5d68,0x 

Idel,0x337e,0x3a2b,0xl99e,0x7520, 

0x544c,0x0377,0x757a,0x781d,0x23a2,0x6a0f,0xlb21,0x634d,0x3476,0x6d5d,0x4ec3,0x36c9,0x7f4f,0x3 

a5a,0x779f,0x32b6,0x52fd,0xl646,0x7e90,0x3al7,0x2147,0x3ceb,0xl0cb,0x0a78,0xl0ba,0xl3fl,0x0dl6, 

0x6c82,0x43fe,0x2980,0x2c46,0xll3f,0xlb6c,0x5695,0x0a78,0x5416,0x0a53,0x7626,0x5fd7 ,0x6743,0x1 

aa4,0x36f5,0x0d3d,0x70cd,0x6fb8,0x2538,0x0e3b,0x2a86,0xleaa,0x595a,0x52cl,0x0185,0x4828,0xl989, 

0x05ed,0xl4b4,0x05c6,0x40b5,0x0el0,0x79e9,0x5d32,0xl61c,0x3bb9,0x77ee,0x7228,0x2549,0x7080,0x 

2db2,0x6077,0x29f 1 ,0x0e5d,0x5d43 ,0x7499,0x4d88,0x 1 0dc,0x6e5b,0x542a,0x 1 9c4,0x756d,0x2839,0x64 

If,0x35d8,0xlc73,0x06eb,0x24e7,0x5a5c,0x23ef,0x3e0e,0x689b,0x5966,0x35cf,0x5024,0x23a2,0x7e90,0 

X79fe,0x2ef9,0x7391,0x7b56,0x097e,0x0017,0x32fb,0xlee7,0x49dc 5 0x6bal,0x5bd9,0xlc64,0x4ed4,0xlc7 

3,0x27ac,0x7b41,0x0708,0x3bdf,0x5cdl,0x4487,0x595a,0x5f8d,0x68d6,0xl9d3,0x047f,0x5elf,0x635a,0x 

3al7,0x781d,0x49dc,0xl49f,0x0bfd,0x4da3,0x7c2f,0x7537,0x374c,0xlac2,0x6fc9,0x61bf,0x73n,0xl^ 

0x6e70,0xl9b5,0x6445,0x02ce,0x62ae,0x68cl,0x519d,0x7a89,0x0f95,0x6e70,0x0bfd,0x6cf3,0x62df,0x03 

5c,0x66ed,0x Ic02,0x2664,0x6a69,0x5be5,0x4dee,0x7aef,0x56cf, 0x2481 ,0x24f0,0x79c2,0x755 1 ,0x2b3f,0x 

7edd,0x5fa6,0x62ae,0x0fd8,0x65c0,0x6d2c,0x3f9c,0x345d,0x3bc8,0x05a0,0x0bea,0x750b,0x4c57,0x6d76 

,0x641f,0x4130,0x3461,0x24cc,0x6cbe,0x375b,0x573b,0xlad5,0x3355,0x4db4,0x097e,0x05a0,0x575d,0x 

483f,0x4aab,0x70cd,0x65a6,0x595a,0xlac2,0xl651,0x6e70,0x5761,0x003c,0xl540,0x2c37,0x2b03,0xlf2f 

,0x2acb,0x668b,0x3476,0x5a3a,0x6d3b,0xldbb,0x31d6,0x3ffa,0x7228,0x3333,0x2f31,0x7998,0x604b,0x6 

e01,0x3693,0x52ea,0xlc3e,0x4604,0x573b,0x572c,0x2b65,0x4dd2,0x3078,0x20d5,0x0e3b,0x2aba,0x456 

4,0x0969,0x73ba,0x3d34,0x5892,0x0723,0x5bf2,0x7c5e,0x36b8,0x7163,0x47aa,0x7b7d,0x210a,0x4803,0 

X3ca6,0x4865,0x7112,0x7850,0x573b,0x4613,0x4afl,0x6371,0x5fbl,0xlaa4,0x01b9,0x4c6b,0x003c,0x6d 

07,0x5e23,0x2d8e,0x4814,0x5309,0x38ce,0x40c4,0xla8f,0xl557,0x5885,0x4398,0x31d6 5 0x20a4,0xl646, 

0x0d4c,0x66c6,0xl3ab,0x0468,0x4f20,0x20d5,0x3fed,0x7e90,0x421d,0x0734,0x543d,0x7n3,0x7537,0x6 

Ca9,0x2ef9£x47e7,0x02f2,0x5al 1, 
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0xledb,0x5a4b,0x420a,0x2a91,0x301e,0x2863,0x035c,0xlc29,0x62df,0x55c9,0x5322,0x766b,0x0d01,0xl 

51a,0x518a,0x6922,0x58f4,0xl4f9,0x2848,0x0e5d,0xlab3,0x2f7c,0x4c0d,0x395c,0x31b0,0xl4b4,0x0bd6, 

0x6754,0x7214,0x52fd,0xlef0,0x01ae,0x0ff3,0xlcl5,0x20b3,0x4b74,0x6011,0x7b6a,0x5a77,0x66b7 5 0x5c 

C6,0x4089,0x058b,0x73ad,0xl086,0x2da5,0x4eff,0x2b4e,0x0fd8,0x6f93,0x32ec,0x52a7,0x6006,0x5e08,0 

X05dl,0xlb0a,0x4662,0x6434,0x3a5a,0x518a,0xl7d4,0x0283,0x3595,0x6194,0x77d2,0x420a,0x43e9,0x6 

02d,0x7f58,0x5bf2,0x5776,0x2812,0xlb21,0xl9ef,0x4b48,0x2aba,0x0e3b,0x5033,0x696f,0x255e,0x409e, 

0x52ea,0x 1 3cd,0x2b 1 4,0x7520,0x337e,0x 1 65 1 ,0x 1 f49,0x669c,0x5776,0x7e87,0x51al ,0x3cb 1 ,0x3767,0x6 

732,0x4b5f,0x076e,0x36b8,0x2575,0x7f64,0xldac,0x08c7,0x035c,0x70da,0x531e,0x7788,0x4b63,0x0969 

,0x6408,0x688c,0x08fb,0x08ec,0x24aa,0x5ced,0x5e34,0x4865,0x394b,0x23c4,0x6c95,0x61e5,0x4c26,0x7 

0da,0x6d4a,0x3c8d,0x31ea,0x5bd9,0x58df,0x5bf2,0x0924,0x29da,0x5all,0x(H54,0x7a89,0x6d61,0x5ca0 

0xl0f7,0x787b,0x68cl,0x090f,0x70ab,0x3324,0x2787,0x2787,0x5f8d,0x49dc,0x7a9e,0x51b6,0x343b,0x4 

3a4,0x0caf,0x2f6b,0x6c95,0x0ce2,0xl488,0x27bb,0x0ce2,0x73dc,0x01b9,0x2481,0x528c,0x06bl,0xldel, 

0x5a60,0xlddd,0x7b0c,0x51ec,0x08ec,0x2c51,0x7b0c,0xl646,0x4f6d,0x0443,0x0071,0xl212,0x3a66,0x5 

378,0x3d08,0x4828,0x637 1 ,0x06c0,0x426c,0x3960,0x49dc,0x6479,0x2848,0x33 18,0x1 7ff,0x40a2,0x4e99 

,0x0419,0x27el,0x2f57,0x2230,0x44ca,0x6a0f,0x4f0b,0xlc02,0x071f,0x23d3,0xlc3e,0x2997,0x3cfc,0x 

e2,0x3a66,0x2b28,0x43b3,0x2dff,0x0311,0x5f8d,0x034b,0x4cla,0x2147,0x344a,0x0918,0x5a06,0x3767,0 

X2dc3,0x4df9,0x27bb,0xll3f,0x4675,0x3a66,0x2de8,0x6922,0xl56b,0x518a,0x23b5,0x779f,0x3c8d,0x0e 

10,0x4781,0x62c8,0x2227,0x40f8,0xll3f,0x6935,0x7df0,0x7105,0x7b30,0x221b,0x301e,0x4796,0x47aa, 

0x2f26,0x3fa0,0x5593,0x29e6,0x462f,0xl646,0x7272,0x7850,0x003c,0x68ea,0x2136,0x344a,0x4f46,0x4 

529,0x4a80,0x3 lc 1 ,0x2227,0x44ca,0x668b,0x6292,0x 1 540,0x7640,0x32fb,0x5d43,0x0e 1 0,0x760d,0x604 

b,0x7daa,0x2 1 0a,0x 1 f2f ,0x77d2,0x5069,0x37 1 6,0x4564,0x224 1 ,0x0bc 1 ,0x635a,0x454f ,0x7ddb,0x4a97,0x 

2230,0x 1 09 1 ,0x3 1 b0,0x36af ,0x 1 7b2, 

0x5024,0x6cd8,0x7f64,0x3009,0x66dl,0x6faf,0x3582,0x3fc6,0x5e79,0x2787,0x6060,0x002b,0xl7c3,0x4 

398 ,0x 1 d90,0x3fed,0x5d7f ,0x74b2,0x 1 0ad,0x7a9e,0x3a3c,0x2adc,0x29bc,0x4859,0x32fb,0x0752,0x6922, 

0x033a,0x6d5d,0x3407,0x5885,0x35f3,0x73f7,0x6e3d,0x7c38,0x7148,0x4b05,0x7163,0x2389,0xl4c5,0x4 

089,0x4ee8,0x23d3,0x7fl5,0x3044,0x3e25,0x264f,0x5761,0x7546,0x58e3,0x55de,0x2790,0x4236,0x220c 

,0x3bdf,0x0d4c,0x090f,0x47db,0x2147,0xll28,0xl99e,0x090f,0x79fe,0x3035,0x5335,0x43b3,0xl4ee,0x5 

b83,0x6434,0xlee7,0x2b03,0x3770,0x5069,0x4ea5,0x2b03,0x6ce4,0x56e4,0x0e3b,0x767c,0x032d,0x417 

d,0x3f9c,0x3b85,0x6e67,0x4e8e,0xl61c,0x56be,0x51b6,0x0779,0x426c,0x0a53,0x5cfa,0xlb21,0x7c75,0x 

7821,0x4b39,0x06bl,0x4558,0x5a4b,0x3e25,0x3770,0x3be3,0xlac2,0x342c,0x4eff,0x38a8,0x6cf3,0x31a7 

,0x01df,0x0b8c,0x4487,0xl9a2,0x3c9a,0x74ff,0x49e0,0x069a,0x0017,0x226a,0x6423,0x7eel,0x5378,0x5 

d25,0x2ed2,0x3883,0xl488,0x4db4,0x417d,0x4acd,0x0933,0x6953,0xl4d2,0x602d,0x2121,0x677f,0xl27 

4,0x52ea,0x395c,0x0066,0xlll4,0x5c8b,0x0e4a,0x2790,0x5e6e,0x3476,0x780a,0x47f0,0x4dee,0x5055,0x 

66c6,0x264f,0x330f,0x7850,0x2aad,0xl0e0,0x5all,0x7097,0x5e52,0xlf38,0x0d01,0x7ebb,0x7386,0x658 

d,0x44ac,0x2ae0,0x0fte,0x2an,0x27ca,0x0(^ 

6faf,0x2874,0xl86a,0x7214,0x2256,0x781d,0xl637,0x2f26,0x7139,0x6194,0x31cl,0x7fl5,0x0cc9,0x40b 

5,0x3dlf,0x2adc,0xlf38,0x529b,0x2b59,0x6371,0xl0ba,0x6183,0x5584,0x6743,0xl81b,0x6ccf,0x0cf5,0x 

3410,0x5al 1 ,0x478 1 ,0x723f,0x65d7,0x3cd7,0x7c49,0x635a,0x20fe,0x7c49,0x35d8,0x04 1 9,0x6fc9,0x23ef 

,0x691e,0x77f9,0x6935,0x5885,0x2d99,0xlae9,0x264f,0x61d9,0x572c,0x70ab,0x227d,0x40b5,0x5d25,0x 

Ic3e,0x61a8,0x7551,0x02f2,0xl67a,0x6f84,0x5be5,0x70e6,0x32al,0x6452,0x02e5,0x574a,0x6bec,0x750 

b,0x344a,0x4b5f,0x5b94,0x6b8a,0x5ffc,0x3960,0x4cla,0x0306,0xl7ff,0x5cfa,0x05b7,0x411b,0x2b72,0 

ab3,0x6b8a,0x77c5,0x6bfb,0x089d,0x220c,0x6292,0x02ce,0x38f2,0x73ba,0x669c,0x29cd,0xl0e0,0x6978, 

0x3d34,0x282e,0x6e2a,0x65a6,0x73ad,0x5892,0xlf62,0x06bl,0x605c,0x2clc,0x44ca,0x6366,0xle96,0xl 

557,0x32ec,0x544c,0x421d,0x7c62, 

0x2dd4,0x4f20,0xl7a5,0x2db2,0x2c20,0xl557,0x5a06,0x4b48,0x4d9f,0x5b83,0x52cl,0x3cd7,0x0708,0x6 

6a0,0x31cl,0x2ed2,0x70ab,0x7836,0x7c62,0x6a24,0x2602,0x484e,0x51ec,0x696f,0x3al7,0x421d,0x55f5, 

0x6a69,0x38f2,0x5584,0x2874,0x748e,0xl526,0xl22e,0xlad5,0x23ef,0x5e23,0x0000,0x2ae0,0x659a,0xl 

9ef,0xlab3,0x3894,0x5bbf,0x2812,0x3bae,0xl7d4,0x0cde,0x5682,0x4c26,0x069a,0x0454,0x40a2,0x56e4, 

0x77a3,0x0e76,0x7b41,0x2615,0x004d,0x6953,0x3022,0xl9b5,0xl0cb,0x32c7,0x2ec5,0x4f46,0x5a60,0x6 

922,0x58df,0x0e07,0x29cd,0x7657,0x3cfc,0x780a,0x20fe,0x6fde,0xlb0a,0x56f3,0x5a4b,0x47e7,0x2629,0 

X780a,0x2e88,0x7080,0x3e32,0x3035,0x7de7,0x24bd,0x44dd,0x3318,0x659a,0x2562,0x0d5b,0x29fl,0x5 

710,0x7c38,0x31d6,0x751c,0x3333,0x4986,0x2bl4,0xlb47,0x7788,0x23f8,0x7148,0x2d8e,0x6725,0xldd 
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d,0x79e9,0x5378,0x51c7,0x6cbe ( 0x4df9,0x4c40,0x6479,0x438f,0x0caf,0x49f7,0x4796,0xl212,0xll72 ( 0x 

0ba7,0x3d08,0x0fe4,0x0e61 ) 0x35a9,0xl9c4,0x7788,0x2da5,0x77a3 ) 0x4ed4,0x761a,0xl51a ( 0x5c9c,0x254 

9,0x5966,0x43b3,0x0071,0x65a6,0x0000,0x6a33,0x3d79,0x2eb4,0x73e0,0x4c6b,0x7e87,0x374c,0x0306,0 

X62f4,0x572c,0x3d79,0x0d01,0x40f8,0x3e54,0xlb7b,0x0bcl,0x0d67,0x3461,0x7097,0x77c5,0x416a,0x60 

60,0x77b4,0x61ce,0x49f7,0x002b,0x453e,0x7eca,0x4db4,0x7a89,0xl239,0x02bf,0x0942,0xlc64,0x2b3f,0 

X3a00,0x44dd,0xl3e6 ) 0x3cd7,0x70bc,0x4502,0x4c57,0xlf38,0x6d4a ( 0x7c04 ; 0x7ac4,0x5378,0xl7e8,0x42 

7b,0x453e,0x5e79,0xl3da,0x372a,0x0d67,0x076e,0xlac2,0x32d0,0x0a53,0x40ef,0x483f,0xl651,0x43c2,0 

X2230,0x632b,0x3355,0xldca,0x43a4,0xlf5e ) 0x6d3b,0x047f,0x5971,0x0cde,0x3d79,0xl67a,0x6183,0x7a 

89,0x6909,Ox56a9,Ox2f7c,Ox034b,0x528c,Ox547O,OxQa6f,Ox73f7,0x0377,0x65a6,0x32c7,0x211d,0x7cl3,0 

X01c8,0x529b,0x01ae,0x5dl9,0x689b,0x2ef9,0x3355,0x0e07,0x3d45,0x7537 ) 0x5593,0x6317,0xl0e0,0x4 

27b,0x6300,0x3ceb,0xll59,0x40f8,0x68ea,0x20c2,()x4558,0x6366,0x47db,0x02a8,0x0a44,0x5335,0x3977 

,0x52fd,0x65fc,0x4c57,0x4141,0x528c,0x226a ) 0x0a6f,0x088a,0x7c62,0xll65,0xl60b,0xl4d2,0x3al7,0x6 

fde,0x3906,0x27dd,0x5042,0x255e,0x786c,0x65d7,0x62f4,0x6cf3,0x208f ,0x7b 1 b,0x 1 526,0x6452,0x68a7, 

0x5fa6,0x74b2,0x5d32,0x3582,0x5322, 

0x23f8,0x4613,0x56f3 ( 0x4da3,0xl0ad ) 0xldf6,0xla98,0x6423,0x3078,0x66b7,0xl9c4,0x0071,0x2c51,0x4 

638,0x2f0d,0x0 Iae,0x465e,0x0779,0x 1 a98,0x597 1 ,0x252f,0x4dd2,0x330f ,0x01 e3,0x3883,0x6b9d,0x5 1 dO, 

0x2an,0x65d7,0x4649,0x68ea,0x44el,0x2f7c,0x58c8,0x3894,0x2673,0x4156,0x77b4 ) 0x2481,0x4859,0x6 

2e3,0x06d7,0x0425,0x392d 1 0x3911,0x4156,0x68d6,0x6944 ) 0x3ca6,0x3333,0xl80c,0x221b,0x5ba8,0x421 

d,0x0a09,0x5cdl,0x29cd,0x033a,0xlf5e,0x65d7 ) 0x70e6,0xl4d2,0x4c40,0x035c,0x05b7,0x7ef6,0x31ea,0x 

02bf,0x24f0,0x3cbl,0x5e79,0x4564,0x3d23,0x5900,0x0425,0x3476,0x484e,0x55e2,0x06a6,0x5e79,0x568 

2,0x345d,0x24aa,0x2615,0x2230 ( 0xl637,0x2389 > 0x44bb ) 0x2ea3 ) 0x3410 > 0xl0n,0x6d07 ,0x4859,0x4127,0 

X2136,0x38e5,0xl263,0xlc58,0x0fbe,0x5bce,0x2f26,0x66b7,0x36e2,0x453e,0x2150,0x0f82,0x44ca,0xlf0 

4 ; 0xlab3,0x462f,0x01f4,0x4515,0x329d,0x216c,0xl9f8,0x2a91,0x6f93,0x58b9,0x56f3,0x6bd0,0xl86a,0x 

4L80,0x076e,0x0425,0x2c7a,0x4eb2,0x0b8c,0x410c,0x65c0,0x08b6,0x285f,0x32fb,0x61a8,0x3fb7,0x5ffc, 

0x77a3,0x7d96,0x2e88,0x5353,0x5f9a,0x0fd8,0xlebd,0x670e,0x0924,0xl25f,0x409e,0x0e4a,0x7b41,0x4 

16a,0x7b0c,0x4236,0x3fdl,0x43fe,0x3355,0x6bec,0x3f8b,0x23d3,0x35e4,0x6732,0x6922,0x3701,0xlafe, 

0xl22e,0x5322,0x282e,0xl81b,0x5024,0x7de7,0x634d,0x3d52,0x06a6,0x74c3,0x4490,0x58f4,0x20a4,0x 

51ec,0x393a,0x5cfa,0x4flc,0x6a0f,0x43d5,0x02bf,0x3e43,0x5bce,0x0752,0x5be5,0x2acb,0xl9c4,0x4ada, 

0x536f,0xl4ee,0x32fb,0x74e8,0xlab3,0x2f0d,0x2805,0x0ff3,0x70e6,0x6fde,0x602d,0x4dc5,0x36b8,0x6ff 

5,0x668b,0xlb7b,0x0caf,0xleaa,0x02ce,0x507e,0x6732,0x5322,0x395c,0x4eb2,0x70bc,0x2874,0x2147,0x 

6754,0x3fc6,0x0fe4,0x5d25,0x4b5f,0x2c46,0x6300,0x3a2b,0x507e,0x4eff,0xl0ba,0x0el0,0x5d0e,0xleaa, 

0x2805,0xlbld,0x74a5,0x3c9a,0x5fa6,0x2aad,0x542a,0x68fd,0x6b8a,0x7821,0x43c2,0x3b85,0x6ce4,0x7 

228,0x7dcc,0x5018,0x5bce,0x36e2,0x55af,0x4cla,0x3e32,0x58df,0xlc58,0x3bc8,0x5cfa,0x3bf4,0x4da3,0 

Xl0ba,0x3a5a,0x29cd,0x08fb,0x6bc7,0x66ed,0x55de,0x43b3,0x7228,0x4eb2,0x2e9f,0x2b3f,0x658d,0x45 

3e,0x4490,0x79c2,0x61ce,0x465e,0x7520,0x4f37,0x2c0b,0x6c82,0x5a3a,0x0723,0x3022,0xl7b2,0x543d, 

0x4dd2,0x6194,0x0bb0,0x40c4, 

0x0bb0,0xll03,0xl50d,0x6285,0x3342,0x760d,0x2b28,0x7f3e,0x61bf,0x08c7,0x6e2a,0x6479,0x5a5c,0x3 

883,0x0ff3,0x217b,0x5a77,0x786c,0x373d,0x6768,0x6fc9,0x465e,0x4a80,0x4986,0xl66d,0xlb47,0x0443, 

0x29cd,0x73ba,0x3e43,0x7ddb,0x226a,0x7f02,0x3977,0x2790,0xl248,0x2227,0x2ed2,0x6944,0x344a,0x 

2f57,0x4247,0x7b27,0xlb7b,0xlebd,0x3f9c,0xl66d,0x0e2c,0x4814,0x5593,0x35cf,0x6479,0x7b30,0x4a8 

0,0x79b3,0xl7a5,0x528c,0x0f82,0x3d6e,0x3a3c,0x724e,0x068d,0x7e87,0x4247,0x0192,0x36de,0x5c8b,0 

X0924,0x3684,0x6bd0,0x787b,0xl526,0x6a7e,0xl212,0xlb0a,0x2549,0x2997,0x0bcl,0x7f64,0x0fbe,0x7f 

O2,0x6768,0x68cl,0x29bc,0x040e,0x059c,0x79e9,0x4f46,0x6ca9,0x462f,0x3al7,0x5a60,0x0fa9,0x7f02,0 

x66ed,0x5fc0,0x5cd 1 ,0x27ca,0xl 397,0x7836,0x3e54,0x7f3e,0x06c0,0x28 1 2,0x3ceb,0x076e,0x 1 7a5,0x62e 

3,0xl9d3,0x68b0,0x0ale,0x2538,0x7b56,0x0a35,0x7c5e,0x4c0d,0x4250,0x5b83,0x6bec,0x4872,0x462f,0 

X7f29,0x2790,0x301e,0x6a24,0x4b63,0x2e9f,0x4db4,0xlef0,0x31cl,0x2d99,0x543d,0x301e,0x6d76,0x66 

a0,0x6d4a,0x51fb,0xl57c,0x36e2,0xl3ab,0xl3ab,0x2b72,0x3a4d,0x2ed2,0x2b72,0x56d8,0x7f3e,0x5d0e,0 

X55b8,0x77d2,0xlfl3,0x0734,0xl989,0x40d3,0x0192,0x0f95,0x3044,0x2acb,0x2496,0x5885,0x0bb0,0x0 

71f,0x4b74,0x780a,0xl0e0,0x4127,0xl637,0x2538,0x410c,0x77c5,0x29e6,0x5fd7,0x760d,0xl4b4,0x5e23 

,0x4e99,Ox6371,0xl557,0xllO3,0x5fa6,0x4515,0xOa6f,0x319b,0x66c6,0xl9a2,0x712e,0x7214,0x3c9a,0xl 

646,0x24aa,0x 1 3cd,0x7 1 39,0x3f9c,0x7c04,0x55f5,0x3 lfd,0x09 1 8,0x62b9,0x3009,0x3d6e,0x3461 ,0x7ef6, 
0x6fc9,0x3dlf,0xl989,0x6a0f,0x4127,0x6bec,0x0918,0x06c0,0x35be,0x36f5,0x5344,0x4ee8,0x7cl3,0x07 
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23,0x787b,0x7fl5,0x66dl,0x49dc,0xl3bc,0xlf49,0x0969,0x3a00,0x70bc,0x0468,0x047f,0xll03,0x3355, 
0x0000,0x5fb 1 ,0x4803,0x2d8e,0x0d2a,0x6a7e,0x 1 1 4e,0x392d,0x089d,0x5be5,0x3cc0,0x2 1 2 1 ,0x4abc,0x0 
ale,0x3911,0x58b9,0x2c6d,0x059c,0x6fde,0x62df,0x79b3,0x7c49,0x7631,0x3ceb,0x7f64,0xlcl5,0x668b, 
0x0752,0x62df ,0x7f73,0x739 1 ,0x52fd,0x7097,0x5e6e,0x7b7d,0x57 1 0,0x4b39,0x2ae0,0x20e9,0x4f5 1 ,0x0f 
a9,0x38ce,0x5d43 ,0x594d,0x20fe,0x 1 205,0x73cb,0x40a2,0x 1 1 59,0x 1 d90,0x68ea,0x 1 ebd,0x 1 aa4,0x003c,0 
xO 1 e3 ,0x346 1 ,0x 1 aa4,0x05c6,0x08fb, 

0x3d45,0x4649,0x224 1 ,0x0a35,0x4 1 56,0x5a 1 1 ,0x7b7d,0x748e,0x3a4d,0x6e3d,0x5e6e,0x543d,0x6f93,0x 1 

3f 1 ,0x 1 6 1 cOxOfcf ,0x 1 60b,0x 1 ecc,0x08ec ,0x35a9,0x7eac,0x63 1 7,0x756d,0x79b3,0x4f6d,0x6 1 94,0x7546,0 

X27el,0x2538,0x5cb7,0x544c 5 0x35a9,0x0d4c,0x7174,0x6423,0x08al,0x24db,0xl7c3,0x4250,0x519d,0x 

7a5,0x46 1 3,0x328a,0x6ce4,0x 1 99e,0x328a,0x779f,0x0b9b,0x47cc,0x7b56,0x01 f4,0x 1 c73,0x2aba,0x3d08, 

0x06c0,0x3fed,0x 1 274,0x4872,0x0e6 1 ,0x6060,0x239e,0x 1 1 28,0x2227,0x545b,0x594d,0x3e 1 9,0x02e5,0x4 

b48,0x2db2,0x0cc9,0x58ae,0x6408,0x6a55,0x2602,0x2664,0x421d,0x438f,0x52fd,0x3d52,0x7203,0x2acb 

,0x3fb7,0x5ced,0x6f93,0x 1 0ad,0x3bc8,0x659a,0x 1 dbb,0x 1 799,0x3 8a8,0x2549,0x 1 eaa,0x2c0b,0x 1 540,0x6 

b9d,0x74a5,0xl841,0x6285,0x0311,0x306f,0x56d8,0xle96,0xld87,0x6dl0,0x329d,0x0e07,0x6e4c,0x640 

8,0xl856,0xll28,0x2664,0xlad5,0x73cb,0x393a,0x6479,0x6a42,0x632b,0x7eac,0x06fc,0x4141,0x29ab 5 0 

X7b6a,0x74c3,0x3977,0x40f8,0xlc4f,0x7b30,0x5344,0x4bl2,0x27ca,0x3d45,0x58ae,0x7b30,0x0fcf,0x5e2 

3,0x761a,0x4abc,0xl9b5,0x4d88,0x6317,0x6935,0x3bc8,0x7272,0x66a0,0x0d70,0x3a5a,0x6bal,0xlc64,0 

X4803,0x2874,0xlf38,0x677f,0x0071,0xlb21,0x2c7a,0x68d6,0x4130,0x6fe2,0x5584,0x757a,0x2389,0x7e 

87,0x3476,0xleaa,0x06eb,0x3324,0x6c95,0x36f5,0x635a,0x5892,0x35be,0x6909,0x0d3d,0x62f4,0xlcl5,0 

X6922,0x2de8,0x06fc,0x0c84,0x301e,0xl841,0x3767,0x61d9 5 0x0fe4,0x4b05,0x05c6,0x454f,0x0306,0x03 

77,0xl540,0x4dee,0x4662,0x73e0,0x0918,0x73cb,0xla98,0xl827,0xlfl3,0x35cf,0x2147,0x2d99,0x0017, 

0x5055,0xl57c,0x7163,0x2230,0x2481,0xle96,0x7f4f,0x7df0,0x047f,0x52b0,0x68b0,0x74b2,0x65eb,0x2 

496,0x0e5d,0x337e,0x32fb,0xll4e,0x5033,0x35be,0x73e0,0x5401,0x0000,0x097e,0x285f,0x5467,0x4e8e, 

0x3b85,0x4ed4,0x62b9,0x5309,0x4156,0x7dcc,0x51al,0x6006,0x0f82,0x543d,0x74c3,0x6e2a,0xl620,0x5 

Cb7,0x2136,0x56e4,0x2da5,0x4dc5,0x282e,0x6922,0x543d,0x393a,0x633c,0x3906,0x5a4b,0x24bd,0x696f 

,0xlb7b,0x4na,0x2549,0x2f0d,0x5f9a,0x73e0,0x55b8,0x7174,0x483f,0x47e7,0x32fb,0x44ac,0x20d5,0x6 

725,0x29e6 5 0x0b8c,0x4b63,0x7ac4,0x0d70,0x227d,0x6e5b,0x2dd4,0x034b,0x6ca9,0x4d9f,0x2241,0x3cd7 

,0x2549,0x5707,0x394b,0x5042,0x2c5 1 , 

0x08b6,0x2acb,0x0306,0x0e07,0xl856,0x211d,0x40a2,0x751c,0x420a,0x7ebb,0x4a80,0xl7d4,0x44f6,0x6 

fb8,0x3bdf,0x4ed4,0x4490,0x2664,0xl3da,0x2dd4,0x6faf,0x40c4,0x0e07,0x5fd7,0x4828,0x3a3c,0x2256, 

0x0734,0x5ba8,0x7203,0x58b9,0x40c4,0x5be5,0x5024,0x44dd,0x2c46,0x66c6,0xlc58,0x5470,0x373d,0x 

7821,0x375b,0x3fc6,0x5dl9,0x02ce,0x0e84,0x7520,0xlfl3,0x420a,0x0e61,0x7080,0x7f58,0x7c62,0x4c5 

7,0x68cl,0x5bce,0x076e,0x40ef,0x36c9,0x5033,0x62c8,0x6fe2,0x4eff,0x5feb,0x31ea,0x3e68,0xl0e0,0x0f 

f3,0x282e,0x7c62,0x2136,0x43fe,0x4c26,0x35f3,0x6dl0,0x6944,0x059c,0x32c7,0x3bdf,0x2615,0x20e9,0 

X3977,0x416a,0xl0ad,0x3369,0x6754,0x2ed2,0x047f,0xlll4,0x4eb2,0x5966,0x05b7,0x2513,0x74d4,0x7f 

3e,0x0a53,0x6366,0x2513,0x5bf2,0x542a,0x6e70,0x4796,0x3d52,0x24f0,0x603a,0x786c,0x035c,0x52cl,0 

X4acd,0x632b,0xl380,0x0734,0x32d0,0xl526,0x6d07,0x79d5,0xlb50,0x74b2,0x27dd,0x7ad3,0xlf5e,0xl 

7b2,0xlc3e,0x3cfc,0x0a44,0x318c,0xl0dc,0x6371,0x6bd0,0x7626,0x7blb,0x06eb,0x7ebb,0x5971,0x7386 

,0x22 1 b,0x0e6 1 ,0x5c9c ,0x7af8,0x0d3d,0x5593,0x70bc,0x5c8b,0x7546,0x 1 67a,0x4c 1 a,0x36b8,0x4 1 7d,0x 

6719,0x55e2,0x3333,0x604b,0x58df,0x70fl,0x5776,0x62ae,0x27ac,0x0a22,0x51ec,0x3al7,0x55e2,0x66b 

7,0x7631,0x4250,0x4f0b,0x5ba8,0xlddd,0x688c,0x6al8,0x5bce,0x7f02,0x7edd,0x55de,0x6bc7,0x0caf,0x 

1841,0x6el6,0x7537,0x0e2c,0x252f,0x748e,0x51ec,0x31cl,0x0454,0x343b,0xl3da,0x38a8,0x58c8,^^ 

e,0x6 1 f2,0x 1 9ef ,0x3d23 ,0x3ceb,0x7998 ,Ox6a33 ,0x4502,0x0d4c,0x2f3 1 ,0x5e23 ,0x79fe,0x 1 0f7,0x3be3,0x2 

fla,0x0000,0x3cc0,0x7f02;0xl4a3,0x0cde,0x255e,0x208f,0x6e5b,0x5593,0x7cl3,0x6077,0x2b3f,0xl0cb, 

0x74d4,0x02d9,0x2dff,0x779f,0x6366,0x5bbf,0xlfl3,0x7546,0x4573,0x7386,0x748e,0x427b,0x5d54,0xl 

e96,0x519d,0x74b2,0x2504,0x5b94,0x0a53,0x3582,0xl4a3,0x68b0,0x3770,0x06a6,0x06fc,0x2673,0x334 

2,0x4aab,0x56f 3 ,0x74e8,0x7537,0x6bfb,0x76 1 a,0x4 1 6a,0x5fc0,0x4e8e,0x6060,0x4dee,0x0 1 f4,0x3022,0x 

4490,0x0a22,0x0734,0x29ab,0x0454,0x4ada,0x0e3b,0x4649,0x343b,0x43b3,0x0745,0xl086,0x2496,0x42 

50,0x5d68,0x6c95,0x70da,0x4b74,0x52ea,0xl248,0x02a8,0x0969,0x670e,0x0283,0x3d6e,0x4e99,0x0924, 

0x6d5d,0x2c 1 c,0x5e 1 f ,0x0a6f ,0x392d, 
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0x4221,0x592b,0x483f,0x51ec,0x641f,0x23d3,0x4c26,0x3c8d,0xl263,0x0955,0x2496,0x7ad3,0x6944,0x7 

dbd,0x0071,0x0745,0x06bl,0x0a53,0x0066,0x0d3d,0x7dcc,0x2496,0x7eca,0x5f8d,0x529b,0x7537,0x423 

6 > 0xl9a2,0x44ac,0x2227,0x4a80,0x3a4d,0x595a,0x0454,0x43fe,0x6423,0x6a42,0x5335,0x7998,0xl7d4,0 

X24aa,0x08c7,0x677f,0x2d8e,0x6953 ,0x2b4e,0x2602,0x70e6,0x7ddb,0x68d6,0x57 1 0,0x06d7,0x 1 ac2,0x52 

a7,0xlf49 ) 0xl526,0xll72,0x27dd,0x7148,0x2b72 > 0x27f6,0x0c93,0x5682,0x32b6,0xl57c,0x4236,0x2de8, 

0x4b5f,0x0b8c,0x05b7,0x5378,0x2b4e,0x74d4,0xl637,0x5d32,0x40a2,0x4c40,0x5b94,0x542a,0x4b74,0x 

0a09,0x5(x)f,0x7f58,0x7d96,0x0bd6,0x4a80,0xl830,0x7b56,0x02bf,0x5467,0x4aab,0xl086,0x4acd,0x001 

7,0x5593,0x79c2,0x62c8,0x52fd,0x73ad,0xl637,0x4f0b,0x4613,0x394b,0x5682,0x7080,0x3cfc,0xlc73,0x 

7d96,0x6d76,0x0e5d,0x2874,0x4f37,0x27ca ) 0xl4a3,0x4872,0x2dd4 ) 0x2562,0x6bc7,0x0cde,0x43d5,0x2e9 

f,0x5682,0x2f7c,0x4a97,0x4991,0xlc29,0xl397,0x767c,0x0c84,0x0708,0x3318,0x2da5,0x7ab5,0x6d2c,0x 

7eac,0x058b,0x6e67,0x3b92,0x750b,0x4b05,0x2f40,0x01e3 > 0xl9b5,0x77f9 ) 0x6a7e,0x05dl > 0x43e9,0x2ad 

C,0x55c9,0x677f,0x66dl,0xl7ff,0x005a,0x2ef9,0x2b28,0x2562,0x6754,0x217b,0xlee7,0x4675,0x55c9,0x 

0f82,0x47e7,0x634d,0x5a77,0x0d70,0x77f9,0x5elf,0x44bb,0x4d9f,0x4872,0xl239,0x7112,0x65bl,0x66b 

7,0x3894,0x4c31,0x0294,0xl9d3,0x6ff5,0x32ec,0x0d70,0x4eb2,0x01e3,0x7daa,0x7eel,0x519d ( 0x7546,0x 

68d6,0x68a7,0x 1 9b5,0xl ef0,0x2f0d,0x2de8,0x29f 1 ,0x23f8,0xl 5 1 a,0x3e43,0x5e34,0x4df 9,0x3e54,0x 1 Ocb, 

0x08d0,0x595a,0x5e6e,0xl0e0,0x7c2f,0x43e9,0xla8f ) 0x0708,0x01e3,0x536f,0x2863,0x62ae,0x7847,0x4b 

05,0xlf04,0x6a24,0x373d,0x3035,0x05ed,0x01b9,0x79a4,0x49f7,0x2227,0x05dl,0x7259,0x58df,0x756d, 

0x785G,0xlc29,0xl7e8,0x68a7,0x0419 ( 0x01f4,0x5761,0x51c7,0x5a77,0x781d,0xl0ad ( Ox69O9,0x4c31,0x5 

707,0x06c0,0x208f ) 0x6732,0x55c9,0x7b27,0x411b,0x6ff5,0x748e ( 0x4d9f,0x221b,0x2997,0x5b83,0xlc4f, 

0x0cc9,0x4558,0x438f,0x0el0,0x4f20,0x3b92,0xlbld ) 0x5055,0x3e7f,0x3fdl,0x217b,0x35a9 ) 0x74c3,0x3 

009,0x23ef,0x4675,0x7eel,0x0a6f,0x6479,0xl239,0x691e,0x4649,0xl3ab,0x0f82,0x7499,0x3894,0x4156, 

0x3318,0xlfl3,0x6a7e,0x7ab5,0x7546, 

0x7eac,0xl086,0x52fd,0x7a89,0x2b28,0x574a,0xlf49,0x0918,0x0bea,0xl397,0x7112,0x3d79 ) 0x66b7,0xl 

dca,0x32ec,0x05c6,0x6c82,0x47e7,0x634d,0x2230,0x005a,0x44dd,0x329d,0xl7ff,0x77f9,0x4f51,0x70fl,0 

X7b0c,0x6909,0x3906,0x3894,0x6ff5,0x7228,0x4398,0x23c4,0x49e0,0xlf62,0xll72,0xl7d4,0x635a,0x5e 

45,0xlb36,0x4141 ) 0x3e43,0x40a2,0x076e,0x32c7,0x3883,0x4814,0xlb0a,0x6408 ) 0x372a,0x7b56,0xl66d, 

0xl61c,0xleaa,0x2496,0x7499,0x51al > 0x0bcl,0x31b0,0x43b3,0x393a,0x4781,0x27bb,0x691e ) 0xl9ef,0x5 

Ced > 0x5e34,0x05c6,0x52b0,0x61d9,0x7c75,0x330f,0xl856,0xl091,0x6183,0x4156,0x392d,0x605c,0xl80c 

,0x2f0d,0xlf04,0x3e54,0x3410,0x73ad,0x5bbf,0x7f73,0x23f8,0xldca,0x0924,0x0bcl,0x06c0,0x059c,0x5 

b94,0x29ab,0x2664,0xl0e0,0x3a5a,0x689b,0x62e3,0x646e,0x2150,0x2121,0xlc73,0x0969,0x4flc,0x5d7f, 

0x23b5 ! 0x0a78,0x394b ) 0x544c,0x0fa9 > 0x003c,0x6e4c,0x4f20,0x3e0e ! 0xll65,0x0e61,0x2adc ( 0x49ba,0x6c 

be,0x08al ) 0x2241,0x66ed,0x4cla,0xl9f8,0x5d68,0x6953,0x38f2 > 0x6ca9,0x761a,0x3d45,0x0ba7,0x5c8b,0 

X2997,0x5344,0x5cdl,0xl263,0x264f,0xl799,0xl60b,0x2980,0x3582,0x2de8,0x337e,0xlddd,0x646e,0x6 

006,0x6743,0x4e8e,0x7f64,0x56d8,0x7788,0x5344,0x786c,0x7e87 > 0x6011,0x344a,0x3al7,0x5all,0x62f4, 

0x3ceb,0x069a,0x6 1 e5,0x6cd8,0x7 1 2e,0x4b63,0x0bc 1 ,0x2863,0x2658,0x2aba,0x73ad,0x68fd,0x 14ee,0x5 

a3a,0xl7a5,0x345d,0x0419,0x4ec3,0x3e54,0x3770 > 0x6fc9 ) 0x3ceb,0x6faf,0xl9b5,0x7640,0x7daa,0x0bb0, 

0x4c57 > 0x7eac,0x38e5,0xldac,0x7f64,0xlfl3,0xll28,0x6d61,0x73ad ) 0x3fa0,0x74a5,0x7203,0x7631,0x3b 

f4,0x2874,0x2c6d,0x4859,0x2c7a,0x306f ,0x58f4,0x52b0,0x4e99,0x79fe,0x4 1 27,0x461 3 ,0x36de,0x4ada,0 

X5d25,0x4db4,0x2f0d,0x49dc,0x3cd7,0x52ea,0xld90,0x2c0b,0x73dc,0x5a5c,0x38f2,0x23d3,0x5elf,0x35a 

9,0x2dc3 > 0x2790,0x24aa,0x3b85,0xl841,0x6el6 ( 0x3044 ) 0x2d99,0xleaa,0x77f9,0x670e,0x7105,0x4f20 ) 0x 

51c7,0x4acd,0xldbb,0x05fa,0x2227,0x4c26,0x373d,0x6d61,0x3767,0x58ae ) 0x7f29,0x7998,0x4986,0x68f 

d,0xl81b,0xldac,0x4e8e,0xl9f8,0x3770,0x4b05,0xl0cb,0x0e76,0xlafe,0x5353,0xl397,0x0fbe > 0x52b0,0x 

5584,0x306f,0x6ff5,0x3582,0x77f9,0x5344,0x3a66,0x0f95,0x602d,0x51c7,0x5042,0x2790,0x49dc,0x0cb8 

,0x6cd8,0x0468,0x77f9,0x409e, 

0x7c75,0x2997 ,0x637 1 ,0x2496,0x2d99,0x4cl a,0x6953,0x 1 1 03 ,0x01 ae,0x4acd,0x 1 856,Ox3ca6,Ox63 1 7,0x5 

19d,0x66c6,0x7847,0x68a7,0x70bc,0x2ec5,0x2b3f,0x7af8,0x3044,0x5ca0,0x24db,0x2f31,0x252f,0x79a4, 

0x593c,0xldf6,0x264f,0x4e99,0x2af7,0x2575,0xl3e6,0x2b65,0x35e4,0x23a2,0xlad5,0x4afl,0xl637,0x6d 

2c,0x01df,0x66a0,0x2clc,0x6e70,0x4814,0x02a8,0x6d2c,0x7b6a,0x55af,0xlef0,0x2863,0x2adc,0xl248,0 

X0468,0x7f64,0x6b8a,0x32ec,0x426c,0x2dd4,0x06fc,0xl856,0x5cfa,0x2f40,0x2241,0xll65,0x27dd,0x221 

b,0xlc64,0x7097,0xl856,0x483f,0x51fb,0x2ed2,0x7657,0x7b56,0x372a,0x5378,0xlee7,0x3cbl,0x306f,0x 

5710,0xl540,0x543d,0x06d7,0x4c7c,0x211d,0x7174,0x6953,0x6978,0x6725,0xl620,0x0cf5,0x5707,0x67 

19,0x0e3b,0x454f,0x65bl,0x6c95,0x43b3,0x5d7f,0x4c57,0x61e5,0x58f4,0x787b,0x55f5,0x5fa6,0x2863,0 
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x55b8,0x7f 1 5,0x2805,0x637 1 ,0x3c8d,0x0425,0x 1 7d4,0x20e9,0x68b0,0x438f,0x0c84,0x438f,0x3770,0x7a 

f8,0x3022,0x7b27,0x0 1 85,0x 1 1 14,0x 1 4c5,0x49dc,0x 1 ecc,0x6 1 ce,0x462f ,0x4 1 6a,0x2a9 1 ,0x4803 ,0x1 a8f ,0 

x25 1 3,0x3ffa,0x7386,0x255e,0x 153 1 ,0x55c9,0x06bl ,0x70ab,0x38a8,0x6909,0x0e07,0x779f,0x 1 78e,0x4a 

ab,0x3d52,0x0d67,0x3324,0x5dl9,0x70fl,0x4803,0x79b3,0x3bf4,0x633c,0x3693,0x44el,0x688c,0x2874, 

0x032d,0x3dlf,0xl263,0x7f3e,0x01f4,0x5ffc,0x68cl,0x6e4c,0x0d2a,0x4d88,0x7c38,0xlll4,0x2e9f,0x572 

C,0x0468,0x4490,0xlb6c,0xl540,0x3582,0x49dc,0x712e,0x06d7,0x0708,0x36af,0x4db4,0x5682,0x05c6,0 

X416a,0x097e,0x0a09,0x62c8,0x2e88,0x2812,0x20c2,0x20b3,0x0969,0xl7ff,0x6cbe,0x02bf,0x70fl,0x0cc 

9,0x0cb8,0x4c6b,0x4f37,0x3el9,0x7ad3,0x252f,0x0969,0x06a6,0x071f,0x4b39,0x52b0,0x3fdl,0x56f3,0x 

3e7f,0x4487,0x0cc9,0x4a80,0x0ce2,0x6479,0xlab3,0x4ec3,0x2549,0x79d5,0x5ca0,0x4flc,0x27ca,0x7626 

,0xl086,0x6cf3,0x0708,0x5971,0x0752,0x7ebb,0x5d7f,0x61e5,0xle96,0x2dd4,0x3ffa,0x5cb7,0x3fed,0x4 

4bb,0x0a53,0x035c,0x6cf3,0x77c5,0x2df¥,0x2812,0x318c,0xll3f,0x06eb,0x6754,0x62df,0x696f,0x6d4a,0 

x4529,0x 1 637,0x0306,0x 1 78e,0x5776,0x7c62,0x74e8 ,0x5 1 ec,0x2f 1 a,0x6 1 bf ,0x6a42,0x7b6a,0x 1531 ,0x7f 

73 ,0x05c6,0x36af,0x2 1 2 1 ,0x5892,0x3 8f2,0x6d4a,0x 1 3cd,0x007 1 ,0x5776,0x344a,0x5 1 a 1 ,0x55b8,0x6285, 

0x004d,0x3770,0x4ed4,0x47e7, 

0x542a,0x23b5,0x02ce,0x29e6,0x68d6,0x724e,0x507e,0x4564,0x097e,0x7f29,0x6944,0x5c8b,0x6371,0x7 

3cb,0x669c,0x2787,0x0a6f,0xlb36,0x0ale,0xl205,0x5f8d,0xl7d4,0x49dc,0x5710,0x01c8,0xlae9,0x088a, 

0x33 33 ,0x224 1 ,0x 1 ac2,0x2dc3 ,0x3022,0x076e,0x7b30,0x2b3f ,0x0432,0x06a6,0x 1 b2 1 ,0x 1 56b,0x7b7d,0x 

7 1 74,0x6 1 a8,0x65fc,0x2230,0x73 86,0x003c ,0x 1 ebd,0x6bc7 ,0x6b8a,0x5309,0x 1 f04,0x 1 830,0x 1 3bc,0x08b 

6,0x01ae,0x61e5,0x6d5d,0x7b0c,0x0cc9,0x2121,0x7b6a,0x6el6,0xleaa,0x4502,0x06eb,0x5a60,0xl086,0 

Xlc3e,0x73dc,0x0ba7,0x4ec3,0x7c62,0xl60b,0x79e9,0x032d,0x3355,0x5bce,0x0d3d,0x2d8e,0x2136,0x01 

C8,0x6ff5,0xlb7b,0x7b56,0x5bce,0x5322,0x0e3b,0xl646,0xl856,0x0d4c,0x08c7,0x6935,0x62df,0x0745,0 

X3bc8,0x4ea5,0x5cb7,0x3355,0x0924,0x5917,0x5695,0x3476,0xl4d2,0x2c46,0x0cde,0xll4e,0x2acb,0x54 

01,0xl60b,0xll4e,0x70e6,0x2147,0x77ee,0x0432,0xle81,0xl57c,0x6faf,0xll03,0x6944,0x2adc,0xl526 

X51d0,0x0bfd,0x0306,0x7ad3,0xl4ee,0xl4a3,0x74ff,0x2b4e,0xlcl5,0x0734,0x5033,0x040e,0xll28,0x21 

6c,0x2b 1 4,0x09 1 8,0x7b27,0x635a,0x 1 e8 1 ,0x4796, 0x047f ,0x53 1 e,0x43a4,0x2dff,0x20fe,0x2c20,0x2a86,0 

x55de,0x6e70,0x7080,0x 1 827,0x0d0 1 ,0x74c3 ,0x70da,0x55e2,0x7e87,0x73f7,0x2602,0x 1 7c3,0x4250,0x2b 

14,0x0fe4,0xl205,0x594d,0x4564,0x594d,0x4f51,0x6d4a,0x5all,0x0cde,0x68fd,0xl9c4,0x2c7a,0x6c82,0 

x38e5 ,0x40a2,0x7df0,0x7 1 48,0x74b2,0x 1 a8f ,0x 1 0f7 ,0x0e4a,0x5e23 ,0x6 1 f2,0x0fbe,0x543d,0x760d,0x73b 

a,0x345d,0x7eel,0x3be3,0x342c,0x3c8d,0x4515,0x4089,0x756d,0x544c,0x32fb,0x36de,0xl989,0xl99e,0 

X0c84,0x4na,0xl9d3,0x5917,0x0a22,0x0bea,0xl557,0x3a3c,0x65d7,0x5a2d,0x3fed,0x38a8,0x32d0,0x76 

40,0x531e,0x2664,0x4991,0x4141,0xlf38,0x5e08,0x575d,0x^ 

0xl091,0x7de7,0x0918 5 0x4141,0x2513,0x781d,0x6011,0xl9d3,0x786c,0xl239,0x7499,0xl25f,0x4a80 
65bl,0x7df0,0x3fc6,0x217b,0x02e5,0x06bl,0x4c6b,0xleaa,0x06fc,0x05fa,0x7214,0x058b,0x74a5,0xlf5e, 
0x594d,0x01b9,0x633c,0x 1 4f9,0x677f ,0x646e,0x 1 b21 ,0x370 1 ,0x01 92, 0x05 a0,0x5042,0x6faf,0x4eb2,0x0 
bb0,0x7836,0x02ce,0x62c8,0x66dl,0x748e,0x65eb,0x3a5a,0x635a,0x394b,0xl9d3,0x4afl,0xl3fl,0x2f26, 
0x52d6,0x576 1 ,0x5378,0x 1 7b2,0x49ba, 

0x2c20,0xl3e6,0x3d45,0x02f2,0x2a91,0x6bd0,0x3906,0x4eff,0x635a,0x691e,0x0443,0x7a9e,0x395c,0x3 

d45,0x44ca,0x05fa,0x51c7,0x44ca,0x55f5,0x56e4,0x5a3a,0x2562,0x252f,0x4564,0x51d0,0x7080,0x2227, 

0x6006,0x24db,0x58f4,0x4c40,0x2c7a,0x6194,0xlf2f,0x6719,0xll65,0x427b,0x002b,0xll59,0x79e9,0x3 

407,0x74c3,0x05fa,0x0752,0x421d,0x5309,0x4250,0x65d7,0x6bb6,0xl61c,0x20a4,0x23c4,0x4dee,0x3369 

,0x5695,0x2812,0x51c7,0x5bce,0x5d7f,0x7f3e,0x6a33,0xl4c5,0x076e,0x2a91,0x3476,0x0b9b,0x2f40,0x5 

19d,0x66fa,0x069a,0x544c,0xl7d4,0x2c6d,0x227d,0x4acd,0x6285,0x0bcl,0x0el0,0x594d,0x0e76,0x5a06 

,0x2dff,0x688c,0x7e87,0x5a06,0x2 1 50,0x346 1 ,0x5bbf ,0x208f ,0x7 1 2e,0x0933,0x5322,0x 1 87d,0x597 1 ,0x0 

d70,0x0fe4,0x438f,0x06eb,0x44bb,0xlll4,0x4649,0xl0f7,0x0a78,0x2b28,0x4aab,0x6a0f,0x282e,0x2b28, 

0x0e2c,0x2602,0x0d5b,0x2f6b,0x32d0,0x4eff,0x4a97,0x2549,0x344a,0x6b9d,0x49cb,0x5707,0x5fc0,0x7f 

64,0x0734,0x3767,0xl0f7,0x35e4,0x52cl 5 0x77c5,0x5cdl,0x263e,0x47bd,0x032d,0x40a2,0x58ae,0x2bl4, 

0x373d,0x55f5,0x49f7,0x0e07,0x285f,0x06bl,0x62f4,0x62f4,0x6754,0x0443,0x0723,0x5bce,0x4d88,0x0 

6bl,0x7b7d,0x65bl,0x66b7,0x31fd,0x2dif,0x6e70,0xl205,0xll4e,0x691e,0x6300,0x5all,0x68d6,0x4ada, 

0x0d5b,0x4da3,0x7ddb,0x06a6,0xl4a3,0xldbb,0x55e2,0xl620,0x0cb8,0x0e61,0x4f46,0x5fa6,0xll3f,0x6 

8d6,0x6b9d,0x739 1 ,0x4ada,0x484e,0x6fc9,0x74b2,0x68c 1 ,0x6ff5 ,0x3022,0x74b2,0x6e 1 6,0x 1 22e,0x0e07, 

0x6317,0x2adc,0x6b8a,0x6c82,0xin5,0x0bd6,0x0e4a,0x0a22,0xl827,0x5d43,0xldbb,0x2dff,0x3bf4,0x71 

1 2,0x0e6 1 ,0x7aa2,0x5ca0,0x6b8a,0x5470,0x047f ,0x343b,0x 1 557,0x7c2f ,0x5e79,0x427b,0x5e45 ,0x3 1 b0,0 
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X438f,0x5e45,0x7112 > 0x4bl2 > 0x2af7,0x56cf,0x7aa2,0x4515,0x79a4,0x0779,0x2256,0x2f57,0x6060,0x6bb 
6,0x5d68,0x5470,0x5d7f,0xlb7b,0x4573,0x220c,0x592b,0x7b27,0x5d43,0x29bc,0x0708,0xlf49,0x4eb2,0 
X6e70,0x5892,0x2de8,0xl7d4,0x282e,0x66b7,0x6944,0x0bfd,0x047f,0x3960 > 0x73e0,0x047f,0x2dff,0x2de 
8,0x55c9,0x0bfd,0x3044,0xl263,0x61bf,0x3c8d,0x4ae6,0x7f3e,0x306f > 0x74ff ) 0x27f6,0x4141 ( 0x0e2c,0x3 
e54,0x089d ) 0x05c6 ) 0x7f29,0x575d > 0x2098,0x4flc,0x6ce4,0x79d5 ) 0x3b85,0x2c0b,0x3fdl,0x0283,0x7148, 

0x56be,0x5fc0,0x592b,0x4865, 

0xl60b,0x4f7a,0x5707 ) 0x47bd,0x68d6,0x781d,0x715f,0x7eca ) 0x0ale,0x56e4,0x0a6f,0x0752,0x7b0c,0x6f 

f5,0x49f7,0x4eff,0x395c,0x318c,0x2f6b ) 0x712e > 0x44f6 ( 0x35cf,0x51d0,0x669c ) 0x7ef6,0xl827,0x7af8 > 0x4 

3fe,0x7788 ; 0x088a ) 0x61e5,0x2538,0x7f64 > 0x3d34,0x786c,0x2a86,0xlee7,0x23a2,0xl397,0x6317,0x7ebb, 

0x658d,0x0283,0x36f5,0x0a44,0x003c,0x668b,0x529b,0x306f,0x634d,0x68ea,0x4ed4,0x6e3d,0xl0ba,0x5 

966,0x 1 248,0x If2f,0x6423,0x08d0,0x77a3,0x40b5,0x6423,0x 1 620,0x2673,0x79c2,0x545b,0x3f8b,0x047f , 

0x635a,0x40c4,0x5033 ( 0x4991,0x2de8,0x5fbl,0x227d,0x2c51,0x6ca9,0x3461 ) 0x5971,0x5ba8,0x0e07,0x5 

a 06,0x4dc5,0x0377,0x02d9,0x344a,0x2b72,0x2a91,0x4f51,0x7640,0x02bf,0x49e0,0x4da3,0x06c0,0x08al, 

0x319b,0x3e25,0x77ee,0x01e3,0x4089,0x4573,0x6719,0xl0e0,0xlafe,0x3cfc,0x02a8,0x31ea,0x3476,0x6 

434,0x2b65,0x602d,0x5bbf ( 0x47aa,0x74b2,0x7080,0xlll4,0x51ec ) 0x3fed,0x3bdf,0x51c7,0x465e,0x20e9, 

0x06eb,0x29bc ) 0x43c2,0xl3e6 > 0x6077,0x47f0,0x2839,0x7f58,0x6ce4,0xl99e,0x06fc ) 0xl091,0x3f9c,0x7a 

9e,0x49ba,0x49cb,0x4c7c,0x5309,0x2e9f,0x766b,0x49dc,0x3342,0x6al8,0x0d5b,0x3d23,0xlcl5,0x23ef,0 

X0cde,0xlac2,0x29da,0xld90,0x420a,0x5335,0x0ce2,0x2db2,0x0a35,0x226a,0x462f,0xl7c3,0xlb50,0x0e 

10,0x2121,0x5018,0x375b,0x545b,0x208f ) 0x603a,0x2e88,0x035c,0x5776,0x32b6,0x3324,0x7c49,0x3b92, 

0x'l4f9,0x05c6,0x6d07,0x5dl9 ) 0x3dlf,0x6d61 ) 0x61d9,0x4b05 ) 0xla8f,0x2ef9,0x55de,0x0a22,0x542a,0x4c 

6b,0x2997,0xl830,0x0c93,0xl526,0x4487,0x4ada ) 0x7631,0x5bd9 ) 0x7c04 ) 0x6719,0x7c49,0x2c6d,0x7640, 

0x465e,0x74b2 5 0xl488,0x65d7 > 0x417d,0xl7e8,0x40f8,0x7b6a,0xla8f,0x44ca,0x5971,0x2848,0x7c75,0xl 

f75,0x6f93,0x6452,0x0a09,0x3e68,0x5018,0x24bd,0xlf75,0x0d70,0x7c38,0x62c8,0x65fc,0x004d,0x2602, 

0x0d67,0x0c93 1 0x7ad3,0xlf04,0x3716,Ox3053,0x630O,Ox3035,0x6bal,0x2136,Ox3Ole,Ox32dO,0x5dOe,0x 

14b4,0x7214,0x4986 ( 0x0d4c ) 0x5cdl,0x0752,0x2787 1 0x5ffc,0x634d,0x4eb2,0x3d45,0xlf04 ) 0x2848,0x08c 

7,0x73ad,0xl4a3,0x5e45,0x097e ) 0x31cl,0x2f31,0x43a4,0x318c,0x5a3a,0x6006,0x7b56,0x0d5b,0x462f,0x 

5bbf,0x6c95 ( 0x0bfd,0x484e,0x2121,0x2664,0x543d,0x0c84 ; 0xl7d4,0x787b,0x5055,0xlef0,0xl239,0x6cc 

f,0x217b,0xl7d4,0x7daa,0x0360, 

0x7788,0x58f4,0x23b5,0xlab3 ) 0x2098,0x0294,0x58e3,0x38bf,0x6423 ) 0xlc3e,0xldac,0x0d3d,0x3053,0x0 

708,0x0779,0x38ce,0x6ff5,0x3e43 ) 0xledb,0x2b65,0x6bal,0xl3ab,0x7551,0x52fd,0x3b92,0x7d96,0xl78e ) 

0x7b6a,0x6944,0x2b3f,0x0283 > 0x5d25,0x531e,0x453e,0xl4ee,0x7520,0x3al7,0x20fe > 0x4398,0x572c,0x5 

917,0x330f,0x3bae ) 0x23c4,0x594d,0x2980,0x5a2d,0x6725 > 0x40c4,0x74b2,0x0918,0x7dbd,0x4ee8,0x345d 

,0x2389,0x09 1 8,0x 19d3,0x7daa,0x6fde,0x36de,0x4b63,0x4dee,0x0752,0x0933,0xl ee7,0x05dl ,0x2 1 7b,0x 

7265,0x32fb,0x786c,0x6e5b,0x66dl,0x3461,0x416a,0x66b7,0x4a80,0x4a80,0x0e76,0x5a5c,0x5682,0x73e 

0,0x40a2,0xl557,0x2ae0,0x31b0,0x2d8e,0x5917,0x31b0,0x4f20,0x7f4f,0x6d76,0xl4c5,0x2f40,0x5cc6,0x 

5e34,0x52d6,0x52a7,0x79e9,0xl61c > 0x3b85,0x071f,0x2bl4,0x6bec,0x2b28,0x5309,0x603a,0x0e76,0x73b 

a,0xl9c4,0x0a6f,0xl3cd,0x0cb8,0x227d,0x751c,0x0a78,0x77f9,0x2150,0x5467,0x0306,0x2b59,0x24f0,0x 

255e,0x7391,0x0fbe,0x47cc,0x5900,0x3cc0,0xl3n,0x6el6,0x08b6,0xl620,0x688c,0xl66d,0x089d,0x2ea 

3,0x208f,0x7821,0x55af,0x2c0b,0x5be5,0xll28,0x6el6,0x5892,0x0745,0x4d88,0x3bae,0x4c6b,0x31ea,0x 

1086,0x7850,0x417d,0x61bf,0x2812,0x4515,0x36e2,0x4b74,0x4cla,0x6408,0x0a09,0x7eca,0xl0e0,0x304 

4,0x01 85 ,0x3684,0x2b03,0x4ada,0xl b36,0x7eca ) 0x6c82,0x49ad,0x757a,0x0bfd,0x3b85,0x52a7,0x 1 ab3,0 

Xl7e8,0x345d,0x20c2,0xld87,0xl531,0x0924,0x6300,0xl25f,0x7b30,0x337e,0x61e5,0x393a,0x3595,0x4 

0f8,0xlb0a,0x3906,0x393a,0xlecc,0x2549,0xlb7b,0x3e32,0x416a,0x5e34,0x7626,0x3fb7,0x3a3c,0x211d, 

0x58ae,0x6d76,0xlee7,0xlc3e,0x6a0f,0x08fb,0x2504,0x6445,0x4d88,0x2f40,0x2i7c,0x6bfb,0x4247,0xl3 

80,0x034b,0x3bae,0x57 1 0,0x5ffc,0x 1 ac2,0x 1 f62,0x7af8,0x29ab,0x7f3e,0x767c,0x62ae,0x0723,0x6faf,0x0 

d5b,0x05c6,0x5bbf,0x0306,0x3cd7,0x4a97,0x44ac,0x27dd,0x0443,0x7ab5,0x47bd,0x4221,0x4573,0x7ad3 

,0x4865,0x27bb,0x5309,0x7b56,0xlc02,0x4236,0xl841,0x4796,0x7139,0x7272,0xll59,0x7c49,0x4502,0 

X0294,0x55c9,0x44ac,0x781d,0xl9ef,0x6bal,0x7847,0x66ed,0x003c,0x4e8e,0x7c5e,0x5e23,0x0192,0x06 

eb,0xl60b,0x252f,0x68cl,0x6452,0x7edd,0x55b8,0x3595,0x27bb,0x5c8b,0x005a,0x47cc,0x689b,0x20d5, 

0xl827,0x500f,0x70bc,0xll65,0x24f0, 
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0x2f26,0x4573,0x285f,0x0fd8,0x65bl,0xl7b2,0x3476,0x3d08,0x7391,0x36c9,0x52cl,0x6366,0x6fe2,0x3 
693,0x4da3,0x23ef,0x2c51,0x38a8,0x646e,0xl22e,0x79d5,0x410c,0x79fe,0x62c8,0x2b4e,0xlae9,0x5695, 
0x2227 ,0x426c,0x761a,0x7c38,0x4afl,0x02a8,0x306f,0x263e,0xlll4,0x7546,0xldf6,0x6f84,0x4089,0x7d 
f0,0x544c,0xl 830,0x4859,0x67 19,0x7eel,0x5c9c,0x0e3b,0x0e76,0x6d4a,0x724e,0x4ae6,0x2980,0x6a24,0 
X7b6a,0x375b,0x7b41,0xl9f8,0x4d88,0xlcl5,0x3369,0xle^ 
3,0x01ae,0x7546,0x31a7,0x44ac,0x0468,0x61^ 

X2da5,0x23d3,0x090f,0x0942,0x0432,0x7dbd,0x3 1 c 1 ,0x 1 50d,0x097e,0x4 14 1 ,0x5fd7,0x0bd6,0x5e45,0x00 

4d,0x5f8d,0x4ea5,0x 1 b47,0x2adc,0x61 f2,0x2997,0x 1 f5e,0x5a5c,0x0955,0x49f7,0x29da,0x 1 49f,0x 1 56b,0x 

01df,0x6d3b,0x3ceb,0x757a,0xlaa4,0x5710,0x6bec,0x70bc,0x3461,0x38d9,0x605c,0x5322,0x6al8,0x51d 

0,0x478 1 ,0x 1 dbb,0x 1 c64,0x2aad,0x4398,0x6bb6,0x6 1 bf ,0x57 1 0,0x3 2fb,0x0cc9,0x4c 1 a,0x4f46,0x3f ed,0x 

29cd,0x2c7a,0xl80c,0x38f2,0xla98,0xl4d2,0x0caf,0x6479,0x4c7c,0x5467,0x20b3,0x5ca0,0x36b8,0xl63 

7,0x6faf,0x5c8b,0x3bb9,0x27ca,0x6408,0x4986,0x5695,0x6a42,0x40ef,0x2f57,0x7b7d,0x7c62,0x2e9f,0x7 

0cd,0x0311,0xl99e,0x0f82,0xl67a,0x6a69,0x748e,0xl7a5,0x0b9b,0x27bb,0xldca,0x06d7,0x7499,0x2ea3 

,0x6a33,0x66c6,0x5dl9,0x3716,0x592b,0x65d7,0xll3f,0x40ef,0x7272,0x7f4f,0x4529,0x56f3,0x20c2,0x6 

e5b,0x2adc,0x3a66,0x058b,0x35d8,0x56e4,0x66fa,0x6d2c,0x002b,0x798f,0x62df,0x6922,0x0fa9,0x3d79, 

0x5707 ,0x748e,0x79c2,0x62f4,0x3767,0x70e6,0x635a,0x4156,0x70cd,0x5fbl 5 0x7b30,0x27f6,0x4afl,0x0 

d70,0x40ef ,0x07 1 f,0x3582,0xO69a,0x23b5,0x5353,Ox23f8,0x 1 1 59,0x7b Ib,0x5e45,0x2f3 1 ,0x0e2c,0x7e90, 

0x77b4,0x5all,0x6194,0x6ce4,0x7265,0xl856,0x3a2b,0x7e87,0x5966,0x2874,0x4db4,0x3d08,0x7b41,0x 

751c,0x2230,0x27ac,0x35a9,0x0caf,0x2ef9,0x5bf2,0x4c40,0x20a4,0x55f5,0x4c31,0x55e2,0x7214,0x0cf5, 

0x40d3,0x781d,0x6e70,0x632b,0xll28,0xl274,0x3 

40b5,0x465e,0x3009,0x7ddb,0xll28 5 0x5bce,0x034b,0x068d,0x5069,0x3d45,0x7edd,0x691e,0x0779,0x67 
43,0x0a09,0x0443,0x4d9f,0xl87d, 

0x5069,0x4247,0xl540,0x529b,0x56d8,0x31fd,0x6f93,0x0a6f,0x3d52,0x4130,0x658d,0xlf49,0x2805,0x4 
dd2,0x3cd7,0x5d25,0x6bc7,0x575d,0x20b3,0x4c57,0x4ee8,0x5d43,0xll72,0x7aef,0x2a91,0x5ffc,0x392d, 
0x5d68,0x02d9,0x2790,0xlf04,0x0f95,0x518a,0x35a9,0x7391,0x2c20,0x38ce,0x715f,0x3f8b,0x2602,0x3 
5be,0xl61c,0x55e2,0x2aba,0x08b6,0x5bf2,0x7n3,0x2da5,0x58e3,0x2f26,0x345d,0x47db,0x3d34,0xll4e, 
0x32b6,0x 1 7c3 ,0x345d,0x 1 ebd,0x7d8 1 ,0x7b6a,0x 1 ebd,0x7080,0x68ea,0x3cb 1 ,0x06eb,0x5d0e,0x5593 ,0x 
668b,0x248 1 ,0x63 2b,0x483f ,0x3 e0e,0x0d2a, 0x64 1 f ,0x7626,0x540 1 ,0x 1 a8f ,0x7272,0x5e 1 f,0x4 1 7d,0x2 1 6 

c, 0x 1 3da,0x68fd,0x 1 0f7,0x7537,0x0066,0x0fd8,0x767c,0x7c2f ,0x782 1 ,0x6ce4,0x7b4 1 ,0x7ebb,0x3a00,0x 
1646,0x0924,0x1 65 1 ,0x5a3a,0x0bc 1 ,0x5a4b,0x05fa,0x44e 1 ,0x Ia98,0x05d 1 ,0x32c7,0x06a6,0x6d61 ,0x5ce 

d, 0x2db2,0x3684,0x0955 ,0x3fc6,0x7998 ,0x0d67,0x0ba7,0xl e8 1 ,0x779f ,0x70ab,0x2b4e,0x4 1 1 b,0x2eee,0x 
6bd0,0x604b,0x0a44,0x6a69,0x483f,0xl637,0xl86a,0x0b9b,0xl263,0x5all,0xle96,0x5900,0x372a,0x2b3 
f,0x5 lal ,0x4dee,0x4a80,0x3d08,0x74e8,0x 1 86a,0x0723,0x2c0b,0x 1 f38,0x755 1 ,0x6cd8,0x2f3 1 ,0x6452,0x 
4814,0x2c46,0x43b3,0x68b0,0x420a,0x3d79,0xl091,0x06fc,0x73f7,0x2658,0xlc29,0x51al,0x6285,0x305 
3,0x2147,0x3d34,0x059c,0x0192,0x47cc,0x05c6,0x0fa9,0x4490,0x4acd,0x4675,0x5776,0x77c5,0x4f6d,0x 
27ca,0x7ad3,0xl81b,0x3324,0x3a66,0x62e3,0x4638,0x5a5c,0x2673,0x2562,0x5f9a,0x3355,0x3e68,0x631 
7,0x0306,0x2b4e,0x68d6,0x5024,0x62e3,0x4f51,0x2997,0x421d,0x2ec5,0x2549,0x23f8,0x55de,0x5761,0 
x36f5 ,0x6fe2,0x47e7 ,0x0d 1 6,0x77d2,0x 1 ac2,0x47bd,0x6e4c,0x4c 1 a,0x5 1 b6,0x 1 7c3 ,0x36de,0x2c0b,0x02 
ce,0x4eff ,0x 1 1 72,0x03 60,0x7537,0x0fe4,0x68a7,0x7 1 39,0x454f,0x6423 ,0x4649,0x4247,0x4c 1 a,0x 1 830,0 
Xl9a2,0xlc29,0x2dff,0x5885,0x43a4,0x4c7c,0x2863,0x62ae,0x2c7a,0x61bf,0x605c,0x20b3,0x7386,0x420 
a,0x48 1 4,0x0000,0x53 1 e,0x766b,0x2a9 1 ,0x3a7 1 ,0x5 1 ec,0x6953,0x426c,0x6bb6,0x20e9,0x24aa,0x4da3,0 
X5d54,0x24cc,0x36b8,0xlf2f,0x2874,0x52fd,0x7de7,0x01f4,0x7228,0x31d6,0x58c8,0x29fl,0xl989 5 0x225 
6,0x6el6,0x595a,0x35a9,0xlb36,0xl0f7,0x58df,0x35e4,0x0955,0x40f8,0x38d9,0x4f0b,0x5335,0xl9ef,0x 
3009,0x 1 9d3,0x5344,0x 1 61 c,0x7 112, 

0xlddd,0x592b,0xl7e8,0xl9ef,0x29bc,0x24cc,0x70ab,0x5d7f,0xl3bc,0xlcl5,0x2clc,0x4a80,0x44f6,0x2a 

dc,0xlc73,0x6944,0x5470,0x6194,0x7df0,0x51fb,0x49ad,0xl49f,0x7850,0x7228,0x0734,0x47aa,0x58ae,0 

X56d8,0x24e7,0x4b63,0x0454,0x426c,0x56cf,0xl0dc,0x35d8,0xl7ff,0x06a6,0x5584,0x36f5,0xl9c4,0x2c2 

0,0x6725,0x7105,0x58df,0x3355,0x06bl,0x0419,0x750b,0x44ca,0x77c5,0x0969,0x7259,0x5a4b,0x2f40,0 

X6a69,0x32al,0x0425,0x52cl,0x2f0d,0x4141,0x2b65,0x6719,0xldbb,0xlfl3,0x4515,0x65c0,0x^ 

Ic,0x5feb,0x0708,0x0066,0xl7a5,0x5917,0x4df9,0x5feb,0x3b85,0xl4ee,0x068d,0xlad5,0x6953,0x2615,0 

X74e8,0x7097,0x0ba7,0x6a55,0x61a8,0x723f,0x7847,0x330f,0xl540,0x0c84,0x7d96,0x73f7,0x4ec3,0x29 

da,0x38e5,0x069a,0x5ba8,0xlecc,0x603a,0xlb21,0x2d99,0x7f3e,0x5ca0,0xlf62,0x285f,0x4db4,0x6ccf,0x 
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528c > 0x4b05,0x3bb9,0x4aab,0x6a0f,0x264f,0x6a7e,0x 1 b7b,0x0bea,0x3035,0x4dc5,0x 1 9c4,0x6d4a,0x3e7f 

,0x5e52,0x0bd6 ) 0x252f,0x3ca6,0x0el0,0x0e5d,0x3e25,0xl4a3,0x5682,0x0fd8,0x393a,0xlf49,0xl4a3,0x2 

513,0x0cde,0x7265,0x3b92,0x5bd9,0x252f,0x3bc8,0xldel,0x5cfa,0xldca,0x55af,0x7386,0x66b7 ,0x4865, 

0x68b0,0x7836,0x6d07,0x2150,0x3a4d,0x23d3,0x2629,0x7ac4,0x421d,0x691e,0x593c,0xlc73,0xlac2,0x 

032d,0x5a60,0x73cb,0x2ec5,0x47db,0x44bb,0x51al,0x6e2a,0x4130,0x0311,0x573b,0x4089,0x29da,0x56 

be,0x3bc8,Ox6b9d,0x6fb8,Ox08c7,Ox73eO,0x7c2f,Oxlad5,0xl086,0x3407,0xl66d,0x3476,0x6cf3,0x5033,0 

X3fa0,0x2538,0x06bl,0x6e67,0x0a78,0x635a,0xlc4f,0x5900,0x6434,0x4573,0x4aab,0x7e90,0x0185,0x3c 

a6,0x4db4,0x06bl,0x004d,0x047f,0x033a,0x0468,0x2256,0x6ccf,0x252f,0x6bd0,0x3369,0x0734,0xl651, 

0x411b,0x32ec,0x7af8,0x5c9c,0x4na,0x0419,0x51fb,0x0bb0,0x5fa6,0xlef0,0x5e6e,0x23d3,0x416a,0x2dc 

3,0xld87,0x68fd,0x2a91,0xl651,0x4529,0xl856,0x6d76,0x7520,0x5042,0x4dc5,0xl7c3,0x6060,0x6366,0 

X51c7,0x65fc,0x7daa,0x47e7,0x7174,0x0d4c,0x3f8b,0x31a7,0x4b5f,0x6fb8,0x56e4,0x4872,0x4662,0x3d2 

3,0x6ff5,0x44el,0x0bfd,0x0283,0x6f93,0x035c,0x49cb,0x779f,0x3044,0x3318,0x2af7,0x3e68,0x0a53,0x0 

b8c,0x7ddb,0x7228,0x392d,0x5a60,0x097e,0x27ac,0xl80c,0x6e4c,0x27el,0x51b6,0x74d4,0x3cbl,0x7c75 

,0x24e7,0x55f5,0x6743,0x779f, 

0x7f02,0x7blb,0x44dd,0x6768,0x4130,0x79a4,0x208f,0x0e76,0x0942,0x4247,0x02ce,0x2658,0x4f46,0x4 

3fe,0x2ea3,0x29fl,0x3595,0x395c,0x5e6e,0x6d2c,0x2d99,0x0752,0x6el6,0x2f7c,0x5cfa,0x416a,0x220c,0 

X090f,0x7aef,0x4156,0xl263,0x574a,0x7203,0x29ab,0x40d3,0x2dff,0x076e,0x79d5,0x2ed2,0x216c,0x01b 

9,0x343b,0x01f4,0x08ec,0x66a0,0x2b3f,0x3el9,0x2863,0xlb0a,0x4398,0x08ec,0x5d54,0x0cf5,0x2dd4,0x 

6b9d,0x35d8,0x3dlf,0x0419,0x3fb7,0x7214,0x61ce,0x29bc,0x2a86,0x3al7,0x62b9,0x29da,0x47f0,0x7db 

d,0x02ce,0x779f,0x79b3,0x5055,0x5b83,0x62b9,0x2af7,0x47aa,0x7520,0x29da,0x4398,0x2549,0xl397,0 

Xl4c5,0x7aef,0x7blb,0xlb6c,0x55b8,0x36f5,0x4828,0x2664,0x73cb,0x7640,0x01c8,0x4flc,0x65bl,0x36 

93,0x4f 37,0x2af7,0x3b85,0x36e2,0x 1 edb,0x604b,0x328a,0x2c7a,0x7546,0x689b,0x7626,0x4 1 0c,0x6e67,0 

x409e,0x21 36,0x3a7 1 ,0x08fb,0x0185,0x6fe2,0x5bd9,0x38f2,0x7080,0x2481 ,0x1 3bc,0x573b,0x43d5,0x2e 

ee,0x5b94,0xlf38,0xl67a,0xldac,0xll59,0x7ac4,0x5ced,0x032d,0x74c3,0x2615,0x5344,0x210a,0xll3f,0 

X0d2a,0x70da,0x2496,0x7163,0x5b83,0x2629,0x071f,0x5bce,0x2227,0x32al,0x79a4,0x0e3b,0x6e3d,0x05 

ed,0x6909,0xl091,0x328a,0x0a35,0x68d6,0x217b,0x5dl9,0xl397,0x70da,0x0924,0x5feb,0xld90,0xl0dc, 

0x3bc8,0x7112,0x7f29,0x6909,0x02f2,0x3bb9,0x519d,0x56cf,0x5cb7,0xlc64,0x5fc0,0x7657,0xl22e,0x2b 

3f,0x6d3b,0x3035,0x090f,0x3fa0,0x31b0,0x3el9,0x3a5a,0x3cc0,0x7c62,0x2848,0x0cc9,0x52a7,0x5593,0 

X0ale,0x5322,0x071f,0x221b,0x3cfc,0xl799,0x6922,0x0a44,0x58c8,0x7850,0x74d4,0x6452,0xldel,0x7b 

30,0x35f3,0x47db,0x58c8,0x3bf4,0x766b,0x49cb,0xl22e,0x5593,0x696f,0x31d6,0xl9a2,0x3d52,0xl7c3,0 

x0b9b,0x7f4f ,0x01 92,0x373d,0x5695,0x6 1 f2,0x 1 0f7,0x6 1 a8,0x0cb8,0x61 a8,0x595a,0x0e4a,0x lddd.Ox 1 e8 

10x0419,0xld90,0x29ab,0x0a09,0x05ed,0x0a44,0x3324,0xld90,0xl0cb,0x2664,0xl0ba,0x0fa9,0x68ea,0 

Xl60b,0xla98,0x282e,0x38d9,0xl488,0x2eb4,0x2dff,0xl380,0x6935,0x5fd7,0x20d5,0x0fa9,0x4b2e,0x76 

57,0x109 1 ,0x32d0,0x3 1 ea,0x4df9, 0x091 8,0x01df ,0x Iee7,0x2d99,0x2ec5,0x 1 989,0x7b7d,0x41 27,0x44dd, 
0x05b7,0x3a4d,0x0d67,0x507e,0x2aad,0x6922,0x24f0,0xlb6c,0x55e2,0x6fc9,0x4398,0x3a00,0x77a3,0x0 

58b,0x0294,0x3770,0x29e6,0xl526, 

0x033a,0x55af,0x5elf,0x6cd8,0x52cl,0x2848,0x7847,0x3693,0x2980,0xl56b,0xl799,0x23ef,0x3fdl,0x0 

8d0,0x7520,0x2ec5,0x536f,0x329d,0xldel,0x66ed,0xl78e,0x3d34,0xl7c3,0x573b,0x0d01,0x6a55,0xl7a5 

0x5e6e,0x4859,0x 1 ecc,0xl 827,0x32fb,0x3e0e,0x3078,0x239e,0x4803,0x263e,0x0f82,0x lcl 5 ,0x0dl 6,0x4 

0ef,0x5353,0xl87d,0x3e7f,0x61f2,0x4865,0x77c5,0x47f0,0x392d,0xl239,0x26O2,0x0419,Ox575d,0x02f2, 

0xl99e,0x658d,0x7f58,0x393a,0x2147,0x798f,0x0dl6,0x3d23,0x61ce,0x528c,0x68a7,0x5cdl,0x4c31,0x7 

edd,0x4c7c,0x35e4,0x5a3a,0x5900,0x696f,0xle96,0x4781,0x5a5c,0x62ae,0x40d3,0x36c9,0x748e,0x0071, 

0x6c95,0x255e,0x761a,0x6e01,0xlb7b,0x4f6d,0xl827,0x767c,0x0dl6,0x4803,0x5a2d,0x5e08,0x507e,0x3 

d45,0x65a6,0x6d61,0x2504,0x3c9a,0x6a55,0x4a80,0x5ced,0x7b30,0xl827,0x767c,0x668b,0x7e87,0x38a8 

,0x31ea,0x6d5d,0xl4f9,0x7105,0x4afl,0x3324,0x798f,0x65c0,0x756d,0x43fe,0x3d23,0x7Obc,0x2098,0x5 

75d,0x220c,0x0779,0x3fc6,0x0el0,0x6423,0xl212,0xl87d,0x4613,0x3369,0x2aba,0x5a3a,0x574a,0x208f, 

0x7dbd,0x6a42,0x4c7c,0x068d,0xlc02,0x2e88,0x0ff3,0x4e99,0x55af,0x6732,0x2504,0xl841,0x6d61,0x2 

513,0x723f,0x2562,0x688c,0x6a33,0x329d,0x3977,0x6011,0x0caf,0x6d4a,0xl22e,0x5ca0,0x5c8b,0xle96, 

0x5ba8,0x23b5,0x3476,0x005a,0x3d79,0x2adc,0x545b,0x6292,0x23b5,0x0066,0x7b27,0x7788,0x635a,0x 

5761,0x24cc,0x7c38,0x35be,0x4bl2,0x38bf,0x61e5,0x6a55,0x4dc5,0x2clc,0xl086,0x3a2b,0x61f2,0x761 

a,0x5d43,0x342c,0x62f4,0x263e,0x4221,0x409e,0x4872,0x6434,0x208f,0x0933,0x221b,0x5cb7,0x77a3,0 

Xl50d,0x0000,0x3044,0x7551,0x5a06,0x6006,0x3d52,0x6d07,0x68cl,0x780a,0x68fd,0x7c04,0x4bl2,0x0 



830 



Copyright ©2004 IEEE. All rights reserved. 



AIR INTERFACE FOR FIXED BROADBAND WIRELESS ACCESS SYSTEMS 



lEEEStd 802.16-2004 



b8c,0x3fc6,0x6a0f,0x43d5,0x79c2,0x659a,0x70fl 1 0x0360,0x74d4,0xll72,0x4796,0x44ac,0x2e9f,0xldf6,0 
x4487,0x66d 1 ,0x343b,0x48 1 4,0x7 1 5f ,0x66f a,0x7e87,0x6e4c,0x4865,0x 1 25f ,0x 1 0ad,0x05d 1 ,0x7 1 74,0x54. 
2a,0x36af,0x0e61,0x5467,0x74b2,0x7b6a,0x6285,0xlb36,0x66a0,0xlef0,0x7788,0x5feb,0x27dd,0x2c37,0 
X7dcc,0x2acb,0xl830,0x239e,0x4c0d,0x3e43,0x27f6,0x02a8,0x5416,0x29e6,0x798f,0x002b,0x77b4,0x4ef 
f,0x4f0b,0x6366,0x3a3c,0x3369,0xl4d2,0x465e,0x61a8,0x4ae6,0x6dl0,0x7daa,0x7821,0x3883,0x40c4,0x 
24db,0x02f2,0x4flc,0x4flc,0x36b8, 

0x6725,0x02f2,0x427b,0x3e43,0x076e,0x529b,0x70da,0x5bbf,0x5bf2,0x0f95,0x7139,0x2b59,0x0f82,0x3c 
fc,0x7c04,0x4991,0xlafe,0x7ab5,0x6479,0x3911,0x5707,0x55de,0x7139,0x5a06,0x0752,0xl4b4,0x4abc,0 
x23a2,0x2adc,0x5335 ,0x5 1 d0,0x4872,0x7259,0x4ee8,0x 1 3f 1 ,0x35d8,0x032d,0x507e,0x68b0,0x32a 1 ,0x05 
8b,0x422 1 ,0x 1 c4f ,0x68c 1 ,0x3a7 1 ,0x4490,0x6408,0x24f0,0x3d 1 f ,0x 1 3bc,0x7f3e,0x62e3,0x3c9a,0x6060,0 
X3355,0x4859,0x715f,0xlcl5,0xlf5e,0x239e,0x373d,0x264f,0x2575,0xlef0,0x5ca0,0x6bb6,0x65a6,0x451 
5,0x3595,0x5917,0x3f9c,0x5309,0x4db4,0x31a7,0xl4b4,0x4638,0x51d0,0x3461,0x5069,0x6011,0x5c9c,^ 
X633c,0xlf5e,0x52d6,0x23ef,0x0d3d,0x6978,0x^ 

e, 0x 1 99e,0x 1 4f9,0x4ada,0x54 1 6,0x5a5c,0x79b3,0x2b28,0x6077,0x2629,0x761 a,0x2b4e,0x528c,0x7c04,0 
X0bb0,0x5695,0x7c2f,0xlf62,0x089d,0x5378,0x677f,0x6e5b,0x0933,0x2b65,0x7a89,0x01c8,0x5776,0x33 
42,0x01e3,0x6d4a,0xl0cb,0x6a55,0x2513,0x5fbl,0xl3^ 

X2839,0x3bb9,0x3693,0x2812,0x4f0b,0x5353,0x3035,0x2af7,0x7ddb,0x7b0c,0x3e32,0x344a,0x4df9,0x0e 
3b,0xl51a,0x62e3,Ox3e68,Ox7c2f,0x65fc,Ox483f,0x5bd9,0x6a33,OxO066,Ox02bf,Ox0e3b,0xll28,0x23d3,0 
X216c,0x4d88,0xlb47,0x79fe,0xll4e,0x0942,0x780a,0x4f6d,0x4ea5,0x36de,0x7080,0x5e6e,0x5344,0x05 
9c,0x4ec3,0x677f,0x593c,0xll72,0x2de8,0x43c2,0x7a9^ 

634d,0x2c6d,0xl989,0x65eb,0xl9f8,0x29cd,0x6fde,0x0708,0x01f4,0x40ef,0xl7e8,0x0f82,0x5all,0xll0 
0x3fed,0x58ae,0x5all,0x70ab,0x05b7,0x3e54,0x4b 

C9,0x5a3a,0x574a,0x02a8,0xl4ee,0xlc58,0x3342,0x6978,0x7f73,0x5467,0x5be5,0x7f29,0x06d7,0x3e32,0 
X3894,0x52d6,0x77ee,0x7a89,0x7b0c,0x0fd8,0x372a,0xl0ad,0x5353,0x73ad,0x3bdf,0xl620,0x49cb,0x21 
50,0x0bfd,0x65bl ,0x3 1 8c,0x lc4f,0xl ae9,0x4eff,0x7ebb,0x4dee,0x 167a,0x08b6,0x23c4,0x7265,0x4aab,0x 
6434,0x52a7,0x2b4e,0x069a,0x05ed,0x38 83,0x4dc5,0x3022,0x4 1 56,0x 1 2 1 2,0x 1 57c ,0x5be5 ,0x01 df ,0x2ad 
c,0x74ff ,0x4d9f ,0x2c20,0x74ff,0x5 1 d0,0x0fd8,0x 1 4c5 ,0x342c,0x 1 620,0x05f a,0x36e2,0x4b74,0x34 1 0,0x 1 
5 la,0x483f ,0x5335,0x7edd, 

0x05ed,0x328a,0x003c,0x224 1 ,0x0000,0x 1 ddd,0x73ba,0x20fe,0x 1 0cb,0x43c2,0x6ba 1 ,0x5a2d,0x73dc,0x 1 
51a,0x5d7f,0x47f0,0x7998,0xl0e0,0x2bl4,0x5e79,0x56a9,0x2bl4,0x05fa,0xl86a,0x65c0,0xl989,0x7657, 
0x7163,0x65eb,0x543d,0x6b9d,0x5e52,0x0000,0x32c7,0x7112,0x342c,0x31b0,0x0a44,0x4df9,0x068d,0x 
6dl0,0x7631,0x7blb,0x7c75,0x01f4,0x6bc7,0x61a8,0x0419,0x08b6,0x3fb7,0x49n,0xl488,0x3d52,0x715 

f, 0x5d54,0x62f4,0x77d2,0xll3f,0x3bdf,0x02 

997,0x29e6,0x5a3a,0x6d76,0x786c,0x35e4,0x6a42,0x6183,0x74ff,0x712e,0x24aa,0xlcl5,0x55af,0x4564, 

0x31ea,0x519d,0x7af8,0x605c,0x3ffa,0x3960,0x035c,0x2c37,0x7097,0x282e,0x79b3,0x0752,0x2848,0x3 

Cfc,0xlf49,0xl526,0x2f40,0x0d70,0x0b9b,0x0e5d,0x3fa0,0x3960,0x757a,0x4872,0x2389,0xl86a,0x2fla, 

0x5f9a,0xlb21,0x2848,0x4130,0x73cb,0x0723,0x6cO,0x2538,0x36c9,0x2b72,0x211d,0x592b,0x6d3^ 

e61,0x20b3,0x4e99,0x5069,0x410c,0x0311,0x751c,0x3fb7,0x0071,0xleaa,0x2538,0x2aad,0x3333,0x7b27 

,0x5cb7,0x0723,0x4d9f,0x2839,0x4236,0x68fd,0x0d4c,0x2805,0x6909,0x79c2,0x0fcf,0x02d9,0x6d07,0xl 

67a,0x2602 5 0xll65,0x427b,0x3d6e,0x5885,0x2256,0xlbld,0x38d9,0x3035,0x0cc9,0x3d6e,0x3d23,0x724 

e,0x531e,0xl4a3,0x5761,0x23b5,0x7836,0x27f6,0x58f4,0x604b,0x02f2,0x4529,0x2538,0x3bae,0x51fb,0x 

3cb 1 ,0x 1 4f 9,0x0fbe,0x2a86,0x29bc,0x44e 1 ,0x372a,0x7c49,0x5 8e3 ,0x2b59,0x63 1 7 ,0x 1 50d,0x3e68,0x4 1 1 

b,0xl99e,0x61a8,0x216c,0x750b,0x2863,0x4649,0x605c,0x2b65,0x7a9e,0x32d0,0x3d45,0x3e0e,0x6944,0 

Xlc64,0x0d67,0x5cdl,0x0d3d,0x3bf4,0x31d6,0x32b6,0x51d0 5 0x08fb,0xl25f,0x66dl,0x0cf5,0x216c,0x2^ 

bb,0x2 1 7b,0x7c5e,0x6732,0x3 1 9b,0x 1 f49,0x3a4d,0x0ce2,0x483f ,0x0723,0x 1 9b5 ,0x4c40,0x2a9 1 ,0x35a9,0 

X6e5b,0x395c,0x44el,0x005a,0x5707,0x417d,0x574a,0x77f9,0x2ae0,0x7d81 5 0x4127,0x602d,0x20fe,0x4a 

da,0x2c6d,0x3el9,0x3324,0x0e61,0x6953,0x4859,0x7c2f,0x4b39,0x6011,0x787b,0x723f,0xl86a,0xlll4,0 

X7821,0x2b4e,0x56d8,0x004d,0x574a,0x604b,0x56a9,0x29ab,0x3b85,0x65bl,0x62f4,0x2997,0x65eb,0x0 

066,0x56d8,0x781d,0x52ea,0x2504,0x3dlf,0x58c8,0xldel,0xl87d,0x5018,0x2629,0x2575,0x757a,0x2c5 

1 ,0x 19b5,0x3fb7,0x594d,0x7 163,0x 1 25f, 
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0x7112,0x38bf,0x58c8,0x68a7,0x29fl,0x7b27 ) 0x70fl,0xl3da,0xl67a,0x3cbl,0x38d9,0x08al,0x757a,0x2 
0b3 ( 0x4b2e,0x2bl4,0x416a ) 0x6a55 > 0x7eel,0x2839,0x2b3f > 0x7836,0xl51a,0x5d25,0x4529,0x24bd ) 0x089 

d, 0x05a0,0x33 1 8,0x4acd,0x391 1 ,0x2dff,0x597 1 ,0x61 d9,0x6cd8,0x01 b9,0x3333,0x79d5,0x2b3f , 0x1 66d,0x 
2790,0x3e43,0x3318,0x7080,0x01f4,0x2549,0x43b3,0x3c8d,0xl67a,0x3960,0xl7a5,0x23f8,0x319b,0xl39 
7,0x31d6,0xl248,0x592b,0x059c,0x79fe,0x05ed,0x285f,0x3c8d,0x3333 ) 0x52cl,0x0fe4,0x2538,0x7cl3,0x 
Iddd,0x2230,0x29fl > 0x5a3a,0x089d,0x38e5 ) 0x518a,0x343b ( 0xl841 ) 0x73e0,0x0fa9,0x51fb ) 0x4781,0x47d 
b,0x3fb7 ) 0x70da,0x2f0d,0xl397 ) 0xlebd,0x61e5,0x27ca,0x32al,0x089d,0x210a,0x7847,0x426c,0x06c0,0x 
6al8,0xl799,0x7148,0xl799,0x3770,0xldbb,0x05dl,0x38d9,0x61d9,0x372a,0x29ab,0x3d34,0x36b8,0x00 
00,0x211d,0x7640,0xl3da,0x3022,0x3f9c,0x35e4,0x2da5,0x79fe,0x5elf,0x5470,0x2098,0x7821,0xl799,0 
X06c0,0xll72,0x01b9,0x43c2,0x319b,0x2d99,0x38bf,0x01c8,0x0708,0x6f84,0xla98,0x3cfc,0x6el6,0x66 
b7,0x633c,0x5416,0x4675,0x36b8,0x73f7,0x3342,0x4236,0x74c3,0x4dd2,0x06d7,0x6183,0x2d99,0x670e, 
0x6754,0x66fa,0xl49f,0x0283,0x641f,0x3f8b,0x7fl5,0x35cf,0x0017,0x5cc6,0x002b,0x4487,0x31a7,0x37 
70,0x4b05,0x55af,0x3e7f,0x420a ) 0x35cf,0x635a,0x7259,0x3d34,0xlf38,0x5584,0x3476,0x32ec,0x2241,0 
X7cl3,0x3476,0x74a5,0x484e,0x5fd7,0x603a,0x3770,0x0fe4,0x49cb,0x06c0,0x5d32,0xl4b4,0x319b,0x33 
18,0x5e23,0x6754,0x4675,0x43a4,0x5a06,0x4bl2,0x0942,0x43d5,0x5d32,0x6cbe,0x6ff5,0x5584,0x6c82, 
0x2f26,0x0e2c,0x7dcc,0x5fd7,0x5a2d,0x35cf,0x572c,0x3bae,0x4b2e,0x0f82,0x7eel,0x7788,0x66c6,0x30 
35,0x5bf2,0x6e01,0x5bbf,0x4eb2,0x3582,0x670e,0x0017,0x3883,0x6f93,0x4ee8,0x5d43,0x3342,0x641f,0 
X6909,0x4f46,0x06eb,0x2eee,0x4490,0x0ale,0x2e88,0x5a77 > 0x2863,0x20c2,0x7228,0x70bc,0x7f4f,0x603 
a,0x6bfb,0x2c51,0x0311,0x0cb8,0x4487,0x2c46,0x0779,0x7626,0x35cf,0x3770 > 0x5d54,0x5ba8,0x5467,0 
X24cc,0x4dd2,0x6cbe,0x5c9c,0x0443,0x6f84,0x6e67,0x5ca0,0x74a5,0x0283,0x3476,0x633c,0x5c9c,0x54 
5b,0x3407,0xl 0dc,0x70ab,0x7265,0x6 1 83,0x68ea,0x 1 57c,0x47bd,0x6e 1 6,0x1 380,0x3e25,0x409e,0x5e23, 
0x454f,0x3cd7,0x6e3d,0x5682,0x779f, 

0x3bae,0x31fd,0x5401,0x7e90,0x0924,0xl4b4,0x2241,0x5ca0,0x5584,0xld87,0x409e,0x7259,0x0fe4,0xl 

9a2,0x0d4c,0x5d32,0xlf2f,0x6371,0x420a,0x438f,0x4649,0x5ced,0x529b,0x77f9,0x7aef,0x2c46,0xla8f,0 

X55af,0x4ee8,0x20fe,0x7n3,0x5e52,0x5fd7,0x301e,0x7ac4,0x7148,0x7eac,0xlb36,0x5966,0x3fc6,0x2f7c 

,0xlc73,0x0d67,0x6el6,0x6bc7,0x4127,0x77d2,0x44ac,0x646e,0xl7ff,0x633c,0x4573,0x6e01,0x49cb,0x5 

335,0x26 1 5,0x696f ,0x3cc0,0x58c8,0x77ee,0x002b,0x 1 1 72,0x0bc 1 ,0x3d52,0x2c20,0x27bb,0x7daa,0x7b0c 

,0x7eel,0x593c,0x5971,0x3369,0x0cf5,0x0el0,0x79d5,0x0425,0x417d,0x08fb,0x2602,0x033a,0x77c5,0x 

781d,0x5018,0x06a6,0x226a,0x7ddb,0x58b9,0xlb21,0xl646,0x38bf,0x24aa,0x01ae,0x38f2,0x5e79,0x076 

e, 0x6fe2,0x7a9e,0xlab3,0x55f5,0x2f40,0x4b2e,0x032d,0x454f,0xlf5e,0x4ee8,0x65d7,0x4aab,0x47f0,0x6 
292,0x79e9,0x58f4,0x32c7,0x3a3c,0x6a0f,0xl841,0x0192,0x7eca,0x02e5,0x0a44,0x3a71,0x4564,0x767c, 
0xl86a,0x2eee,0x02f2,0x4ea5,0x6d3b,0x4ae6,0x2eee,0x394b,0x688c,0x6194,0x3960,0x2673,0x3d45,0x2 
f6b,0xle81,0x0432,0x4675,0x545b,0x4781,0x0955,0x7d81,0x6fb8,0x6d07,0x6732,0xlf49,0x62e3,0xlb6c 
,0x5be5,0x4e99,0x4872,0x56cf,0x4c0d,0x0e76,0x6bec,0x3a3c,0x344a,0xl651,0x3bdf,0x7391,0x5e34,0x3 
d52,0xl99e,0xl7d4,0x66a0,0xlf38,0x36c9,0x0a09,0x0e3b,0x3333,0x65fc,0x65bl,0x5e23,0x3b92,0x2e9f, 
0x2c51,0x0a44,0x0caf,0x724e,0x6cd8,0x6e3d,0x3b92,0x4f7a,0x3595,0xl212,0x2481,0xl67a,0x77ee,0x2 
Clc,0x4da3,0x68cl,0xl4b4,0x44f6,0x318c,0x08ec,0x6d4a,0x6bal,0x4dee,0x3e0e,0x6077,0x5a3a,0x032d, 
0x36de,0x519d,0x2Bl,0x32b6,0x6452,0x40d3,0x756d,0x4859,0x7af8,0x3906,0x62f4,0x65eb,0x40d3,0x5 
353,0x724e,0x6371,0x416a,0x5ba8,0x689b,0x0e2c,0x79fe,0x47f0,0x73f7,0x79a4,0x4ec3,0x6e2a,0x02f2,0 
X0311,0x2562,0x4828^)x7631,0x255e,0x4662,0x3693,0x4ed4,0x4156,0x4na,0x4872,0x2615,0x6366,0x7 
9e9,0x3d08,0x536f,0x65d7,0x641f,0x4b39,0x4c0d,0x23b5,0x500f,0x4991,0x2acb,0xl9ef,0x751c,0x5776, 
0xldca,0x23ef,0x2b03,0x4ae6,0x2ef9,0xlae9,0x43e9,0x5ba8,0x4afl,0x5467,0x52fd,0xll03,0x5069,0x2b 
28,0x4ed4,0xl0dc,0x7847,0x2eb4,0x5fd7,0x08b6,0xOcf5,0xO443,0x4b2e,0x003c,0x5a5c,0x3684,0xl9d3,0 

x02d9,0x01f4,0x2980,0x7259, 

0x2aba,0xll72,0x2d99,0x7dcc,0xl57c,0x6944,0xl841,0x58f4,0x7f02,0x0071,0x31cl,0x70fl,0x44bb,0x2 

9e6,0x29cd,0x79c2,0x29fl,0x36f5,0xlf75,0x01b9,0x5a3a,0x4156,0x55af,0xll28,0x0969,0x68ea,0x68ea, 

0x47db,0x4a80,0x7ab5,0x32c7,0x483f,0x4afl,0x2629,0x3053,0xl0f7,0x7105,0x7ebb,0x44el,0x306f,0x6 

183,0x73ba,0x3894,0x2bl4,0x2f6b,0x3a66,0xll59,0x38bf,0x4dd2,0x0969,0x0bfd,0x2f0d,0x08fb,0x2658, 

0xl9d3,0x49dc,0x7657,0xlae9,0x08fb,0x2980,0xl9ef,0x574a,0x27bb,0x2848,0x2389,0x7537,0xl56b,0x4 

828,0x5bbf,0x62ae,0x23a2,0x2fla,0x0dl6,0x2b3f,0x3476,0x5353,0x65bl,0x239e,0x2af7,0xl0ad,0x20c2, 

0x5e23,0x65bl,0x5cc6,0xl22e,0x0d01,0x23f8,0x4b48,0x68d6,0x7c62,0x2b4e,0x61a8,0x0f82,0x6077,0x3 

01e,0x5024,0xl4b4,0x6dl0,0x2812,0x409e,0x47aa,0x56a9,0x3be3,0x2c20,0x5ba8,0x06c0,0x2c7a,0xld87 
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,0x2db2,0x372a,0x44bb,0x7ac4,0x4649,0x2b65,0x285f,0x0723,0x3cfc,0x0caf,0x7821,0x3410,0x3bf4,0x3 
911,0x02ce,0x395c,0x343b,0x605c,0x36b8,0x604b,0x2562,0x7174,0x47bd,0x32fb,0x0419,0x2787,0x486 
5,0x5344,0x0ce2,0x4f20,0x 1 57c,0x73ba,0x7f ^ 

14e,0xl3bc,0x392d,0x23ef,0x2f0d,0x7d96,0x62df,0x5be5 J 0x6faf,0x6a33,0x2147,0x329d,0x712e,0x73dc,0 

X2b4e,0x724e,0xldel,0x3d34,0x0a35,0x7df0,0x05a0,0x5d54,0x27f6,0xl60b,0x4cla,0x781d,0x2e9f,0x58 

e3,0x68a7,0x4872,0x689b,0x0cde,0x3716,0x3d6e,0x6bc7,0x3767,0xll65,0x7520,0x70da,0xl9f8 J 0xlf38, 

0x40b5,0x409e,0x4a80,0x3078,0x0fe4,0x529b,0x6bc7,0x696f,0x4f7a,0x3461,0xl0ba,0xl60b,0x0a6f,0x42 

Id,0x5fc0,0x4529,0x0f95,0x7537,0x069a,0x2f0d,0x7265,0xl4d2,0x3d23,0xl86a,0x5elf,0x071f,0x3078,0 

X2c20,0x6c95,0x3cfc,0xlac2,0x02a8,0xl4b4,0x4b63 j 0x7520,0x6a0f ) 0x5900,0x605c,0x0fa9,0xl67a,0x29a 

b,0x4814,0x24f0,0x3al7,0x40c4,0xl7b2,0x6cf3,0x5bce,0x2a91,0x51al ) 0xl531,0x35e4,0x438f,0x23ef,0x 

318c } 0x61d9,0x52cl,0x62c8,0xl7a5,0x2b3f,0x20a4,0x06d7,0x7f64,0x6060,0xl488,0x689b,0x73ad,0x238 

9,0xl380,0x2615,0x6d61,0x2863,0xl3da,0x3693,0x58c8,0x0e76,0x3d34,0x68ea,0x220c,0x0a6f,0x5707,0 

x0066,0x034b,0x05b7,0x750b,0x3f a0,0x 1 0e0,0x2db2,0x49f7,0x 1 7ff,0x27ac,0x677f ,0x3369,0x08c7,0x2f0 

d,0x0294,0x7dbd,0x5 19d,0x32al , 

0x31a7,0xl0e0,0x677f,0x36e2,0x7836,0xl49f,0x2230,0x3d23,0x7e90,0x7821,0x2538,0x5d43,0x0fcf,0x6 

a42,0xl7c3,0x5e08,0x2629,0x3cbl,0x4a97,0x6194,0x08fb,0x0360,0x35d8,0x43e9,0xl57c,0xl248,0x5069 

,0x069a,0x409e,0x 1 7c3,0x55f5,0x5feb,0x7b30,0x55b8,0x77f9,0x36af,0x 1 380,0x4529,0x 1 397,0x77a3,0x0 

a6f,0xl799,0x06eb,0x4781,0x696f,0x77b4,0x6d3b,0x766b,0x20b3,0x40ef,0x01b9,0xl7c3,0x3bdf,0x7a89, 

0x2150,0x5593,0x7163,0x0468,0x3770,0x0468,0x529b,0xl380,0x409e,0x3595,0x2e9f,0x7fl5,0xl799,0x 

6a69,0x483f,0x62df,0x01df,0xlf49,0x529b,0x5695,0xlfl3 I 0xlbld,0x20fe,0x227d,0x6978,0x7ebb,0 

,0x3cc0,0x(H25,0x40a2,0x43a4,0x0bfd,0x677f,0x4c31,0x760d,0x7e87,0x7228,0x5416,0x6183,0x6d5^ 

4e8e,0x6c82,0x760d,0x5917,0xl80c,0xlc02,0x748e,0x5bd9,0x7788,0x43a4,0x2b72,0x4487,0xl4ee,0x67 

7f,0x5fa6,0x77ee,0x7ebb,0x0745 ,0x 1 c4f ,0x40a2,0x3cc0,0x 1 ecc,0x 1 086,0x 1 620,0x208f ,0x058b,0x6d5d,0x 

3d79,0x0d5b,0x01df,0x0e61,0x723f,0x2af7,0x5710,0x7228,0x7520,0x6978,0x7163,0x4c57,0x23f8,0x6e5 

b,0x7ab5,0xlbld,0x79a4,0x20fe,0x47bd,0x462f,0x3e54,0x47f0,0xl827,0x0dl6,0x0e76,0x3355,0x5353,0x 

5d7f ,0x 1 d87,0x28 1 2,0x0a53 ,0x5470,0x7626,0x4b74,0x5a60,0x0955 ,0x3e32,0x 1 dca,0x3d52,0x220c,0x42 

6c,0x2bl4,0x6f84,0xlc29,0x73cb,0x58f4,0x5d32,0x7b41,0x7f02,0x4dc5,0x44bb,0x3bb9,0x4796,0x4b74, 

0x0377,0x0cc9,0x24cc,0x4dd2,0x6a24,0x5a77,0x3c8d,0x2ec5,0x62f4,0xl205,0x329d,0x4ee8,0x52ea,0x3 

e0e,0x7551,0xl50d,0x6bfb,0x6408,0x32b6,0x7163,0x2a86,0x0306 ) 0x301e,0xldf6,0xlee7,0xl212,0x6bec, 

0x0d5b,0x 1 c73 ,0x634d,0x73dc,0x766b,0x3053 ,0x03 1 1 ,0x7eac,0x65c0,0x4dc5 ,0x7 1 74,0x7265 ,0x66ed,0x 

66a0,0x68b0,0xlb7b,0x6cbe,0x068d,0x6bd0,0x62c8,0x4604,0x3al7,0x4df9,0xll03,0x3cc0,0x462f,0x65f 

C ) 0x3a66,0xl0f7,0x62f4,0x088a,0x3476,0x7ac4,0x0723,0x5a3a,0xldel,0x4502,0x32fb,0x602d,0x0ce2,0x 

1380,0x52cl,0xldca,0x2de8,0x465e,0x74ff,0x5d43,0x58c8,0x6d4a,0x3d23,0x7b0c,0x20b3,0xlf38,0x0bfd 

,0x01c8,0x7dcc,0x6d3b,0x6d5d,0xla98,0x0a78,0x36de,0x35cf,0x6011,0x0192,0x3883,0x44ca,0x08b6,0x 

4814,0x602d,0x70ab,0x66ed,0x2ef9,0x786c,0x7c38,0x70fl,0x0f82,0x3fc6,0x3ffa,0x4f46,0x24bd,0x798f, 

0x0d70,0x0fcf ,0x 1 1 28,0x2 1 50,0x24cc, 

0x0000,0x0017,0x723f,0x4b5f,0x2c20,0x0cb8,0x688c,0x68ea,0x6cf3,0x61f2,0x4b48,0x2848,0x29fl,0x54 

16,0x31ea,0x659a,0x6768,0x4ee8,0x6434,0x646e,0x5d25,0x7551,0x4b05,0x417d,0x670e,0x239e,0x20c2, 

0x3be3,0x3716,0x263e,0xl0ba,0x670e,0x40d3,0x70e6,0x2d99,0x40c4,0x5elf,0x4flc,0x4250,0xl651,0x3 

Cd7,0x3595,0x216c,0x05ed,0x4abc,0x5584,0x0419,0x0969,0x49ad,0x592b,0x2098,0x70cd,0x5353,0x375 

b,0x3a5a,0xl67a,0x0723,0x6a33,0x4127,0x602d,0x38a8,0xlaa4,0x409e,0x2b28,0x62f4,0x0969,0xl3cd,0 

X3693,0x3e25,0x373d,0x4156,0x32al,0x6dl0,0x2513,0x62ae,0x36e2,0x4a97,0x7e87,0x4c0d,0x43fe,0x0b 

9b,0x0933,0x23d3,0x20c2,0x2098,0x43fe,0x4abc,0x68b0,0x7dbd,0x3bb9,0x2863,0x38e5,0x343b,0x7139, 

0x574a,0x43c2,0x08al,0xl4a3,0x4781,0x2787,0x35f3,0x4a80,0x069a,0x7847,0x02ce,0x7df0,0x255e,0x6 

77f,0x3461,0xlc73,0xl4b4,0xl57c,0x798f,0x58e3,0x226a,0xl526,0xlafe,0xl3e6,0x2acb,0x0e4a,0xledb, 

0x79a4,0x20c2,0x6909,0xl67a,0x723f,0x3770,0x49f7,0x5917,0x06fc,0xl9ef,0x01e3,0x2ae0,0x787b,0x7e 

el,0x49e0,0x4991,0x4da3,0x3582,0x7537,0x6366,0x337e,0x2a91,0xl9d3,0x40b5,0x01f4,0x003c,0x2098, 

0x08al,0x4529,0x2aad,0x2eb4,0x6bfb,0x438f,0x0f95,0x3fdl,0x5885,0x416a,0x0e4a,0x3e54,0x089d,0xl9 

89,0x20e9,0x574a,0x43fe,0x0bea,0x51fb,0x6e4c,0xl7ff,0x08ec,0x4991,0x79e9,0x2136,0xll72,0x43e 

2615,0x411b,0x071f,0x01b9,0x29ab,0x263e,0x38bf,0x0360,0x3cbl,0x319b,0x798f,0x2538,0x217b,0xl4a 

3,0xl0ad,0xlef0,0x3e32,0x3595,0x2575,0x6e5b,0x6a0f,0x6e01,0x059c,0x43fe,0x465e,0xlae9,0x6479,0x 

7626,0x7148,0x73n,0x65d7,0x74ff,0x0306,0x3e32,0x7f02,0x7b30,0x3a3c,0x2562,0x5584,0xl0ad,0x5a2 
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d j 0x65fc,0x5f8d,0x5033,0x5416,0x2575,0x2673,0x2658,0x6e5b,0x0fcf,0x77a3,0x3bdf,0x337e,0x2481,0x 

3c8d,0x3cb 1 ,0x 1 dca,0x4398,0x43c2,0x3369,0x4c7c,0x5fa6,0x62c8,0x6e0 1 ,0x6f 84,0x03 1 1 ,0x3b92,0x264f 

,0x27f6,0xlecc,0x035c,0x208f,0xl086 > 0x43c2,0x0443,0x465e,0x2615,0x6a0f,0x7a9e,0x49n 5 0x766b,0xl 

799,0x4c0d J 0x4acd ) 0xl3cd,0x3022,0x05a0,0x4d9f,0x35be,0x7ab5,0x79b3,0x2658,0x51fb,0x3767,0x32c7, 

0x5378,0x2150,0x670e,0xlbld,0x5322,0x7ad3,0x6768,0x0969,0x2eb4,0x6006,0x5401,0x2496,0x05dl,0x 

6a33,0x3894,0x3d6e,0x24bd,0x6b8a, 

0x5elf,0xl9d3,0x410c,6x3d08,0x7c04,0x5cfa,0x6a42,0x23c4,0x3582,0x5401,0x0bb0,0x2ed2,0x56be,0x3 

e68,0x36c9,0x6e67,0x43d5,0x0360,0xlb7b,0x61ce,0x786c,0x519d,0x0d5b,0x5bd9,0x05dl,0x604b,0xl25 

f,0x0e61,0x4c40,0x0cf5,0x373d,0xlc58,0x7259,0x6cbe,0x4ada 5 0x05a0,0x7657,0x5e08,0x74b2,0x5344,0x 

5776,0x58b9,0x4bl2,0x6bfb,0x6479,0x29cd,0xlaa4,0xl81b,0x3906,0x0017,0x373d,0x6292,0x2a86 } 0x4df 

9,0x5a5c,0x372a,0xl7a5,0x31d6,0x35d8,0x70bc ) 0x2f26,0x36e2,0x484e,0x4b74,0x6317,0xl7c3,0x4221,0 

X5018,0x264f,0x0000,0x23f8,0x7c75,0x2805,0x32d0,0x4986,0x786c,0xl56b,0x6fb8,0x43e9,0xlb47,0x46 

1 3,0x00 1 7,0x0454,0x 1 c02,0x2863,0x28 1 2,0x7e87 ,0x2eb4,0x 1 4c5 ,0x2b4e,0x3d79,0x5 6e4,0x757a,0x3c9a, 

0x79d5,0x44f6,0x2150,0x2nc,0xlc3e,0x32b6,0x70cd,0x79a4,0x0bea,0x4638,0x0294,0x24cc,0xl248,0x0 

b9b,0x55e2,0x20c2,0x6743,0x40f8,0x3d23,0x0a6f,0xlebd,0x605c,0x02bf,0xl830,0x3a2b,0x6d2c,0x6a7e, 

0xlad5,0xll72,0xlf62,0xlab3,0x7fl5,0x20b3,0x2ea3,0x22 

2df,0x2513,0x7ad3,0x798f,0x5900,0xll59,0x7aef,0xl9f8,0x49cb,0x6077,0x66a0,0x77b4,0x20e9,0x74e8, 

0x5f9a,0x7551,0x5fd7,0x0d2a,0x3461,0x3770,0x7f4f,0x35be,0x634d,0x5467,0x0a09,0xlc64,0xl60b,0x5 

Cb7,0x2256,0x74b2,0x4acd,0x4828,0x36e2,0x0933,0x74c3,0x751c,0x7dcc,0xlf2f,0xll03,0x4872,0x73f7, 

0x3ca6,0x3e7f,0x7105,0x2fla,0xl827,0x4865,0x2d99,0x65eb,0x0fa9,0xlf75,0x6935,0x0d4c,0x531e,0x4f 

20,0x44ac,0x2d8e,0x507e,0x5e34,0x2b4e,0xl0f7,0x0fd8,0x52ea,0x5885,0x02ce,0x572c,0x43b3,0x4bl2,0 

X7f29,0x5fc0,0x5761,0x05ed,0xld90,0x08al,0xl540,0x330f,0xldac,0x4dd2,0x6719,0x6fde,0x420a,0x79c 

2,0x658d,0x227d,0x3960,0x4865,0x604b,0x2f57,0x70e6,0x4796,0x6c82,0x2c37,0x2c37,0x6cd8,0xlb50,0 

X4250,0x49dc,0x51c7,0x7de7,0xl3da,0x7b56,0x7259,0x6b9d,0x2clc,0x3cd7,0x2ed2,0x77c5,0x3410,0x0c 

e2,0x7821,0x5917,0x7537,0x2fla,0x7640,0x4221,0x3ceb,0x44bb,0x7d81,0x0432,0x2f31,0x573b,0x0d70, 

0x0e76,0x 1 248,0x787b,0x 1 c4f ,0x3c8d,0x3d 1 f ,0x23a2,0x3bae,0x007 1 , Ox 1 1 3f,0x0 1 df ,0x5a06,0x0fe4,0x6d 

76,0x4564,0x592b,0x79c2,0x01b9,0x592b,0xll4e,0xl380,0x55de,0x0306,0x216c,0x51ec,0xle81,0x5c9c, 

0x3e25,0x3bf4,0x3bc8,0x55b8,0x632b, 

0x342c,0x4573,0x0cb8,0x66fa,0xl50d,0x27ca,0x4dd2,0x56cf,0x3d23,0x668b,0x573b,0x040e,0x5e6e,0x4 
65e,0x29bc,0x0fa9,0x4eff,0x603a,0x51b6,0x6d4a,0x217b,0x6732,0x2481,0x31fd,0x6a24,0x5682,0x2980 5 
0x0745,0x2549,0xl7a5,0x27f6,0x29e6,0x4cla,0x0bfd,0x7b7d,0x3^^ 

28,0x6bec,0x2f57,0xl3ab,0xl3ab,0x08c7,0xl80c,0x7080,0xl0dc,0xl7a5,0x7391,0x40ef,0xl0cb,0x56f3,0 
X32d0,0x658d,0x58b9,0x5elf,0x4f6d,0x55c9,0x7998,0x2adc,0x6e4c,0x0ale,0x62e3,0x32d0,0x426c,0x4b 
2e,0x2b59,0x595a,0x7edd,0x06eb,0xl9f8,0x301e,0x6bec,0x24f0,0x7e87,0x7f29,0x221b,0x330f,0x0d70,0 
X7214,0x35cf,0x7788,0x5776,0x4649,0x3a3c,0x38f2,0x3d52,0x05b7,0x0c84,0x5fc0,0x757a,0x47cc,0x01 
92,0x2c6d,0x7c62,0x603a,0x3be3,0x6183,0x35cf,0x5a4b,0x0723,0x7de7,0xlafe,0x4986,0x3022,0x7eac,0 
x6434,0x2dc3,0x6a55,0x3960,0x7163,0x(M01,0x36b8,0xl799^ 

62,0x4db4,0x 1 56b,0x69 1 e,0x 1 f 04,0x676 8, 0x7f 1 5, 0x20a4,0x6a55 ,0x263e,0x7f73 ,0x4ec3,0x2c5 1 ,0x43fe,0 
X01f4,0xl9f8,0x6faf,0x2673,0xl57c,0x61ce,0x3324^ 

0,0xl841,0x3cfc,0x7dbd,0x343b,0x2230,0x2c20,0x4803,0x4649,0x7blb,0x2b28,0xl205,0x7dbd,0x7c5e,0 
X2c46,0x220c,0x24bd,0x3407,0x24e7,0x2150,0x27ca,0x593c,0x5e45 5 0x56d8,0x2b72,0x43d5,0x06a6,0x4 
662,0x7174,0x23ef,0xlb6c,0x3ceb,0x2f6b,0x4ec3,0x500f,0x0cc9,0x2da5,0x5a60,0x4afl,0x544c,0x3894,0 
X4c7c,0x2adc,0x7eel,0xlc29,0x2150,0x485 

5b,0x3684,0x3701,0x7f73,0x5033,0x2e9f,0x5024,0xl557,0x77d2,0x6dl0,0x56f3,0x5900,0x4814,0x0fd8, 
0xl274,0x51c7,0x5344,0x2db2,0xl3e6,0x002b,0x3fa0,0x4130,0xl263,0x70fl,0x5d32,0x208f,0x7fl5,0x3 
d52,0x29fl,0x6f84,0x6d07,0x5bbf,0x632b,0x076e,0x0ba7,0x65fc,0x4089,0xl3fl,0x4502,0x4398,0xle96, 
0x780a,0x0294,0x6922,0x4089,0x44f6,0xl50d,0x6ca9,0xl9d3,0x32b6,0x328a,0x6953,0x68fd,0x4865,0x0 
bea,0x264f ,0x5 1 8a,0x5e23 ,0x25 1 3 ,0x5e52,0x0c 

0xlc02,0x4ea5,0xl0dc,0xlf5e,0x076e,0x0377,0x52ea,0x27bb,0x4781,0x2839,0x7c2f,0x0294,0x3fed,0x5b 
d9,0x5cfa,0x779f,0x417d,0x3053, 
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Ox 1 b0a,0x20c2,0x2f57,0x689b,0x2e9f ,0x090f ,0x 1 84 1 ,0x45 1 5,0x 1 edb,0x3333,0x5966,0x7f 1 5,0x65a6,0x3 
a7 1 ,0x780a,0x 1 239,0x7847,0x226a,0x227d,0x6al 8,0x7b7d,0x7640,0x453e,0x6bd0,0x0283,0x465e,0x5f 8 
d,0x4986,0xl531,0x6366,0x2997,0x7ab5 ) 0x342c,0x0bea,0x7097,0x5033,0xl248,0x3906,0x632b,0x6c82,0 
x6d3b,0x 1 989,0x4236,0x748e,0x09 1 8,0x74d4,0x77d2,0x5695 ,0x6el 6,0x 1 c4f ,0x2562,0x542a,0x4ea5,0x2 
504,0x6452,0x7b4 1 ,0x4f7a,0x5024,0x0cb8,0x3a4d,0x089d,0x4c0d,0x06fc,0x3a2b,0x2aad,0x42 1 d,0x0a6f , 
0x2f7c,0x 1 8 1 b,0x43e9,0x4c6b,0x2629,0x73f7,0x 1 274,0x5761 ,0x4af 1 ,0x58f4,0x0b8c,0x4529,0x 1 ecc,0x5b 
bf,0x3a66,0x531e,0x2805,0x3906,0x4flc,0x73dc,0x5971,0x4d88,0x255e,0x3d45,0x2874,0x38a8,0x0d2a, 
0x6ff5,0x5cfa,0x51fb,0x01c8,0x36de,0x2c7a,0x454f,0x02d9,0x38bf,0x005a,0x572c,0x01c8,0x5018,0xlc7 
3,0x034b,0x5e79,0x5 1 a 1 ,0x 1 f2f,0x73ba,0x4da3,0x3fb7,0x 1 df6,0x0b8c,0x 1 9f8,0x545b,0x7f4f,0x55 84,0x5 
Ced,0x0000,0x462f,0x438f 5 0x670e,0x55af,0x5ffc,0x536f^^ 

35f3,0x6ccf,0x2eee,0x4df9,0x2dff,0x73ba,0x74e8,0x0955,0x2bl4,0xlc02,0x3053,0x6423,0x4db4,0xl380, 
0x3883,0xll28,0x6423,0x0e5d,0x44ac,0x393a,0x52b0,0x5d68,0x216c,0x6953,0x08al,0x6c82,0x23d3,0x 
1 e96,0x7de7,0x43c2,0x2b3f ,0x 1 ebd,0x23 89,0x24bd,0x4b39,0x5900,0x6ba 1 ,0x047f ,0x 1 9b5 ,0x 1 1 1 4,0x 1 64 
6,0x7b0c,0x715f,0x2673,0x0185,0x23b5,0x4649,0xl397,0x592b,0x2e9f,0x08d0,0x5682,0x633c,0x70cd,0 
x40d3 ,0x3bb9,0x67 1 9,0x265 8,0x483f, Ox 1 6 1 c,0x7aef ,0x05d 1 ,0x739 1 ,0x345d,0x2 1 2 1 ,0x0f 95,0x4 1 27,0x08 
C7,0x55de,0x0745,0xlcl5,0x0933,0x36b8,0x2ed2,0x05dl,0x4eb2,0x5a06,0x51b6,0x3701,0x2b28,0x239e, 
0x01e3,0xla8f,0x696f,0xl50d,0xlf75,0x0708,0x5b94,0x6f93,0x4e99,0x5ca0,0x6d3b,0x5378,0x02e5,0x6 
8ea,0x55c9,0x 1 274,0x4dc5 ,0x 1 830,0x79a4,0x32b6,0x3369,0x7 1 48,0x4dee,0x6434,0x7 1 39,0x4490,0x57 1 
0,0xl0ba,0x6bfb,0x319b,0x2575,0x306f,0x3ffa,0x65fc,0x43a4,0x61a8,0x5a06,0x06bl,0x5bf2,0x371^ 
7d4,0x6e3d,0x0311,0x6a42,0x2098,0x047f,0x7203,0x2ae0,0x32al,0x7626,0x4ea5,0x74b2,0x38ce,0x670e 
,0x6al8,0x0360,0x05c6,0x47db,0xld87,0x7a89,0x344a,0xl086,0x766b,0x0fbe,0x23c4,0x0e76,0x484e,0x 
2ea3,0x79fe,0x Ib47,0x77a3,0x 1 99e, 

0x2c46,0x73e0,0x602d,0x65a6,0x3al7,0xl99e,0x4d88,0x7eca,0xl488,0x6d5d,0x421d,0x24aa,0x4502,0xl 

b21,0x2874,0x0425,0x766b,0x3a4d,0x691e,0x3cd7,0x216c,0xldf6,0x5e08,0x4781,0x3a4d,0x79b3,0x35d 

8,0x2b59,0x3a5a,0x646e,0x6011,0x2f0d,0x2496,0x73ba,0x7c04,0x02bf,0xl0dc,0x29cd,0x767c,0x2eb4 5 0x 

66ed,0x4250,0x68ea,0x 1 3e6,0x6a0f ,0x0955 ,0x50 1 8,0x 1 a8f ,0x68fd,0x66b7,0x3 1 c 1 ,0x6944,0x 1 3ab,0x35e 

4,0x5e52,0x4236,0x6292,0xlf38,0x696f,0x0b9b,0x2aad,0x0c93,0x5f9a,0x4b2e,0x35be,0x4127,0xlf5e,0x 

79e9,0x62b9,0x0933,0x02bf,0x715f,0x0745,0x35cf,0x2ae0,0x36af,0x6a24,0xlae9,0x4236,0x7272,0x58f4, 

0xll65,0x35a9,0x529b,0xl637,0x20a4,0x0e61,0x453e,0x7ad3,0x3342,0x2f40,0x750b,0x74d4,0x20a4,0x4 

0d3,0x5feb,0x65fc,0x6bec,0x659a,0x7214,0x0bea,0x5f8d,0x6011,0x7ef6,0x2a91,0x7163,0x337e,0x44ca,0 

x02f2,0x68c 1 ,0x 1 f3 8,0x23c4,0x44e 1 ,0x1 c64,0x6d6 1 ,0x06d7,0x59 1 7,0x6bc7,0x7ddb,0x4aab,0x4c6b,0x 14 

9f,0x4c40,0x5776,0x6ca9,0x02e5,0x56cf,0x7386,0x0969,0x071f,0x4c31,0x27ac,0x0d3d,0x536f,0x4d9f,0x 

1 f62,0x 1 c4f ,0x282e,0x7a89,0x5 8b9,0x27dd,0x5e45 ,0x3 1 b0,0x 1 eaa,0x7259,0x27dd,0x3 8ce,0x35d8,0x74e 

8,0xl0cb,0x575d,0x6719,0x52a7,0x3el9,0xldac,0x66a0,0x372a,0x4a80,0x602d,0x221b,0x760d,0x73e0,0 

X2ef9,0x3f8b,0x3be3,0x68fd,0x06d7,0x0071,0x06fc,0x7c04,0x724e,0x0ff3,0x65d7,0x059c,0x2f31,0x7e90 

,0x3767,0x4f6d,0x329d,0x0419,0x2848,0x5b83,0x005a,0x0dl6,0x65bl,0x2121,0x4e8e,0x24db,0x5be5,0x 

3333,0xl989,0x2b28,0x49dc,0xl57c,0xl557,0x61f2,0x0c84,0x688c,0x6f93,0x7657,0x426c,0xl0ba,0x3a 

I,0x374c,0x40f8,0x27ca,0x462f,0x318c,0x7228,0x56f3,0x3883,0x3a4d,0xl620,0x43e9,0x393a,0x3e25,0x 

252f,0x77c5,0xlaa4,0x5e45,0x0d2a,0xl9ef,0x4b48,0x3ca6,0x0ba7,0x3e32,0x0a6f,0x6011,0x3d52,0x528c 

,0x27bb,0x6479,0x55b8,0xlee7,0x2f6b,0x3078,0x3369,0x0f95,0x47cc,0x7163,0x40ef,0x035c,0x4ed4 

918,0x0933,0x49e0,0x0a35,0xla8f,0x5055,0x2da5,0x74ff,0x4f37,0x40ef,0x5470,0x3b92,0x417d,0xl3da, 

0x2eee,0x6434,0x51b6,0x06a6,0x7daa,0x73ad,0x033a,0x285f,0x58df,0x0752,0x6bb6,0x36f5,0x35a9,0x3 

Iea,0x097e,0x531e,0x3cfc,0x7d81,0x4bl2,0x2241,0x79fe,0x5a06,0xlafe,0x6f93,0x211d,0x5d43,0x438f,0 

x32ec,0x68d6,0x01 85,0x4638, 

0x3cc0,0x0a09,0x542a,0x7c5e,0x5ffc,0x7836,0xl488,0x6300,0x5c8b,0x6bd0,0x6bd0,0x58df,0xl4c5,0x3 

078,0x3693,0x575d,0x7f58,0xl22e,0x677f,0x518a,0x6006,0x7139,0x4f0b,0xl4ee,0x417d,0x4dd2,0x5a5c, 

0x411b,0x392d,0x5322,0x787b,0xl0ba,0x7214,0x23b5,0xl212,0x7eel,0x7ac4,0x0cc9,0x66c6,0x7f3e,0x6 

bb6,0x5fbl,0x38bf,0x5917,0x2997,0x01df,0x7f64,0xl9d3,0xl086,0x574a,0x27f6,0xin5,0x3035,0xl397, 

0x2136,0x5cdl,0x4156,0x2839,0x3009,0x5971,0x040e,0x787b,0x6f84,0xldca,0xld87,0x593c,0x635a,0x 

6bc7,0x02bf,0x2227,0x6366,0x5d25,0x255e,0x5a5c,0x5707,0xlc02,0x2230,0x58ae,0x6ca9,0x097e,0x077 

9,0x7272,0x6725,0x593c,0x6317,0x427b,0xl799,0x5bf2,0x6bal,0x6060,0x646e,0x66c6,0x255e,0x4781,0 

X282e,0xl7e8,0x7499,0x24bd,0x4d88,0x573b,0xl091,0x3e7f,0xlebd,0x0377,0x2bl4,0x2d99,0x3e25,0x6 



Copyright © 2004 IEEE. All rights reserved. 



835 



IEEE Std 802.16-2004 IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS-PART 16: 



8b0,0x5a77,0x3a5a,0x55f5,0xlll4,0x43c2,0x5ba8,0x24f0,0x088a,0x4ed4,0x5042,0x31b0,0x4564,0x2bl4, 

0x0443,0x4662,0x0283,0x3716,0x77b4,0x2787,0x40a2,0xldel,0x5584,0x0723 > 0x0752,0x5ffc,0x6d61,0x 

0a22,0x658d,0x4db4 ) 0x220c,0x7de7,0x0a22 ) 0x4487,0x05c6,0x0185,0x5cb7,0x712e,0x3e54,0x4638,0x7a 

89,0x7aa2,0x4f0b,0x6743,0x0d4c,0x5ba8,0x3 1 8c,0x763 1 ,0x2c46,0x79fe,0x2504,0x78 1 d,0x786c,0x5a3a,0 

X43b3,0xlb47,0x66fa ) 0x20d5,0x35f3,0x6ca9,0x6011,0x0185,0x29fl,0x2eee,0x2f57,0x79d5,0x7f64,0x4c0 

d,0xll65,0x27dd > 0x70e6,0x2629,0x49ad,0x68a7,0x239e,0x20d5,0x5344,0xl3ab,0x7214,0x0d3d,0xldel,0 

xlef0,0x6292,0x 1 9a2,0x5dl9,0x7386,0x 1 165,0x lb6c,0x If 1 3,0x5 1 ec,0x4c7c,0x4a80,0x2 147,0x68d6,0x5e 

34,0x543d,0x6d2c,0x56d8,0xl4a3,0x5d25,0x6e5b,0x0d2a,0x7386 ) 0x7821,0x0e76,0x44el,0x090f,0xl3da, 

0x55c9,0x005a,0x58b9 ) 0x5a2d > 0x0e5d,0x3e7f,0x5e34,0x2f7c,0x0el0,0x7097,0x0d4c,0x08ec ) 0x4089,0x3 

8ce,0x49ba,0x4ed4,0x3bae,0x41 6a,0x2c37,0x0 1 ae,0x6292,0x4872,0x3 Ifd,0x3cc0,0x6cbe,0x5cdl ,0x 1 25f , 

0xl856,0x62c8,0x56be,0x659a,0x40c4,0x0d70,0x4ee8,0x7105,0x4b39,0x55f5,0x7dcc,0x6ce4,0x394b,0x6 

8a7,0xlae9,0x633c,0x633c,0x329d,0x47f0,0x6953,0x0O4d,0x5e23 ( 0x4c7c,0x7ac4,0xl856,0x5335,0x2147 

,0x7821,0x0e4a,0x715f,0x0955,0x208f,0x2ed2,0xl9ef,0x0d4c,0x0e07,0x3ceb,0x6e2a,0x73dc,0x32ec,0x0 

8d0,0x329d,0x7cl3,0xlb6c,0x058b,0x3911, 

0x35a9,0x27f6,0x2fla,0x29bc,0x659a,0x68a7 1 0x6d61,0x417d,0x31cl ) 0xlebd,0x7d96,0xl3cd,0x420a,0x2 

0a4,0xlb50,0x38e5,0xl3bc,0x4487,0x35a9,0x7847,0x3407,0x0cf5,0x56cf 1 0x29da,0x6bec,0xll3f,0x56a9, 

0x08d0,0x0745,0x40d3,0x2dd4,0x5c9c ) 0x0fe4,0x7af8 ) 0x0bb0,0x6978,0x62b9,0x7c38,0xld87,0x47e7,0x3 

fc6,0x779f,0x0454,0x68b0,0x210a,0xldel,0x5fc0,0x49ba,0x0c93,0x691e,0x595a,0x4abc,0x5042,0x088a, 

0x01f4,0xl25f,0x35cf,0xl3fl,0x74a5,0x0071,0xl25f ( 0xl856,0x51d0,0x5cc6,0x3ca6,0x0ba7 ) 0xll59,0x52 

a7,0x 1 87d,0x500f,0x4 1 30 ) 0x38f2 ) 0x328a,0x3bb9,0x55c9,0x4b39,0x2c7a,0x7f3e,0x2805,0x3 1 a7,0x0955,0 

x5a77,0x6faf,0x53 1 e,0x73ad,0x756d,0x668b,0x7 1 12,0x73cb,0x7dbd,0x 1 856,0x 1 78e,0x70da,0x3 1 a7,0x7d 

aa,0x70e6,0xl60b,0x77ee,0x5bf2,0x7ddb,0x543d,0x3b92,0x6e70,0x5a77,0x6944,0x20e9,0x4dc5,0xlee7 > 0 

X4dd2,0xl51a,0x7d81,0x05dl,0x7112,0x5bce,0x38ce,0x543d,0x7112,0x2a91,0x723f,0x0283,0x2af7,0xla 

C2,0x5900,0x7272,0x2clc,0x410c,0x01f4,0x79e9,0x6fc9,0x7998,0x0bfd,0x7aa2,0xl212,0x3044,0x3a66,0 

X227d,0x2575,0x4flc,0x2549,0xl212,0x61bf,0x56e4,0x4502,0x3894,0x32ec,0xlddd,0x6fe2,0x003c,0x24 

db,0x210a,0x6d3b,0x409e,0x7ab5,0x6fc9,0x6d5d,0x51d0 ) 0x748e,0x4828,0xlad5,0x38d9,0xlf38,0x79b3, 

0x544c,0x4859,0x5b83,0x32c7,0x5695,0xl9f8,0x2ea3 ) 0x51b6,0x70bc,0x68cl,0x3911,0x52ea,0x6e3d ; 0x7 

3f7,0xl78e,0x68cl,0x23ef ; 0x669c,0xl274,0x3d79,0x05fa,0x3b92,0x3fed,0xl56b,0x226a,0x32fb,0x5b94, 

0xl540,0x5ca0,0x6d07,0x5a77 > 0x5fc0,0xll65,0x2eee,0x56e4,0x7499,0x4c6b,0x27f6,0x27ac,0x52fd,0xll 

4e,0x3a7 1 ,0x2f 3 1 ,0x 1 172,0x40ef ,0x6ff5,0x 10ad,0x08fb,0x6c95,0x0a53,0x032d,0x47bd,0x62f4,0x7b30,0x 

180c,0x66ed,0x2ec5,0x004d,0x7ebb,0x6922,0x5892,0xll3f,0xlf04,0x5d68,0x49e0,0x723f,0x2dc3,0x4abc 

,0x44ca,0x6a33,0xlb36,0x3b85,0x0cf5,0x5dl9,0x08fb,0x573b,0x507e,0xl3da,0x426c,0x7ef6,0x2ef9,0x2 

136,0x002b,0x427b,0x2504,0x5069,0x40f8,0x6d3b,0x507e,0x70ab,0x0bd6,0x5378 ( 0x6194,0x5900,0x693 

5,0x4e99,0x6f93,0x069a,0x7626,0x52ea,0x211d ( 0x0a22,0x0fcf,0x24aa,0x5d68,0x7228,0x7b56 ( 0xl4b4,0x 

If49,0xl380,0x7df0,0x2615,0x7c62 1 0x2f6b,0x4e99,0x3e54 ) 0x24e7,0x5309,0x68cl,0xlef0,0x7c5e,0x2fla, 

0x2c5 1 ,0x4a97,0x4 1 7d,0x2b65, 

0x2848,0x02f2 ) 0x2clc,0x6077,0x4675,0x5584,0x5d68,0x5344,0xll72,0x7850,0x4ae6,0x38e5,0x7cl3,0x2 
55e ( 0x779f,0x56d8,0x6cf3,0x3a3c,0x3410,0x7657,0x372a,0x5elf,0x6754 ( 0x05b7,0x4573,0x35e4,0x6060, 

0x43c2,0x37 1 6,0x6e5b,0x3a00,0x5f9a,0x4bl 2,0x Ic73,0x35be,0x5fd7,0x61 bf,0x394b,0xl 6 1 c,0x6725,0x0 

33a,0x24db,0x088a,0xlef0,0x6a42,0x5416,0x29fl ) 0x6743,0x5d32 ) 0x7640,0x6cbe,0x0432,0x4b48,0x0d01 

,0x0a35 ( 0x696f,0x65d7,0x77f9,0x0432,0x73e0,0x3a3c,Ox2fla,0xl651,0x255e,0x5d7f,0x3701,0xl827,0x7 

998,0x36e2,0xl4ee,0x4487,0x7c04,0x0e3b,0x08al,0x3d08,0x4ada,0x0bd6,0x3701,0xldbb,0x0cf5,0x61ce, 

0x6e4c,0x0bcl,0x77b4,0xlb6c,0x6a55,0x345d,0x4564,0x2389,0x786c,0x724e,0x4127,0x43e9,0x4flc,0x5 

fd7,0x2acb,0x4604,0xl488,0x668b,0xlae9,0x47e7,0x5a4b,0x40c4,0x239e,0x6e01,0x7b27,0x29da,0x5c8b, 

0x5885,0x059c,0x263e,0x0a6f,0x3684,0x7546,0x3cbl,0x068d,0x4ae6,0x282e,0x6e2a,0x0fcf,0x20a4,0x47 

f0,0x44bb,0x56d8,0x2e88,0x4a97,0x66fa,0xl4c5,0x40b5,0x6faf,0x798f > 0x0ale,0x3d23,0xl0cb,0x5d0e,0x 

6fc9,0x529b,0x27ca ) 0x4acd,0x781d,0x65d7,0x2aba,0x7112,0xl67a,0x5ced,0xl651,0xl3e6,0x3053,0x675 

4,0x2227,0x66fa,0x0b8c,0x7f4f,0x5309,0x6f93,0x6cbe,0x51d0,0x0d2a > 0x06fc,0x0fe4,0x2664,0xlb0a,0x0 

a35,0x393a,0x5018,0x696f,0x2e88,0x2256 ( 0x5d68,0x49ad ) 0x6ce4,0x715f,0x2241,0xl799,0x7a89,0x20a4, 

0x7631,0xlb47,0x44el,0x6300,0x5042 ) 0x0360,0x6371,0x3770 ) 0x0el0,0x66b7,0x787b ) 0x7499,0x330f,0x 

If38,0x5all ) 0x3bc8 ) 0x29da,0x4221,0x3e0e,0x6e01,0xlf62,0x421d,0x0432,0x2b4e,0x2b65,0x24bd,0x642 

3,0xl3ab,0x0bb0,0x43fe > 0x3318,0x3716 ) 0x0955,0x66dl,0xl4a3,0x7631,0x211d,0x6cd8,0x0a53,0x0468,0 
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x454f,0x 1 637,0x5 1 fb,0x637 1 ,0x7640,0x7386,0x58b9,0x2602,0x6768,0x74c3,Ox5885,0x3e68,Ox 1 56b,0x2 
Ild,0x0ba7,0x4c40,0x31fd,0x02f2,0x426c,0x374c,0x4b2e,0x4ada,0x058b,0x7edd,0x3cd7,0x6bal,0xl526, 
0x0723 ,0x7b27,0x3e43,0x3a5a,0x48 1 4,0x 1 c64,0x47f0,0x lc 1 5,0x35e4,0x03 1 1 ,0x59 1 7,0x44ac,0x79e9,0x2 
787,0x3461,0x38ce,0x4a97,0x02a8,0x3e25,0x239e,0x0dl6,0x06eb,0x0419,0x3bdf,0x43b3,0x373d,0xl4c5 
,0x0360,0x604b,0x7f58,0x2c37,0x5e34,0x38bf,0x2b3f,0x6e4c,0x4f46,0xl620,0x3e25,0x7 174,0x5322,0x6 
754,0x7228,0x0a09,0x4828,0x44dd, 

0x3 1 fd,0x69 1 e,0x2c46,0x7ddb,0x2b59,0x 1 ddd,0x7d8 1 ,0x2ae0,0x62df ,0x0 1 e3,0x3 1 b0,0x7c04,0x0745 ,0x7 
b6a,0x0000,0x 1 e8 1 ,0x58f4,0x01 92,0x5a77,0x4089,0x62c8,0x7 1 2e,0x0e3b,0x49ba,0x6a24,0x4529,0x3355 
,0x77ee,0x49cb,0x43a4,0xl7a5,0xl0ba,0x342c,0x5a06,0x217b,0x0d67,0x4130,0x2eb4,0xl56b,0x79a4,0x 
5fd7,0x3e25,0x2b72,0x55e2,0x306f,0x77a3,0x504 

0x7657,0x0955,0x0419,0xl3ab,0x393a,0xl856,0x5322,0x2241,0x7a9e,0x6183,0x08d0,0x5fd7,0x0000,0x 

780a,0x7ef6,0x0e61,0x62c8,0x5c8b,0x2812,0x5d68,0x2dd4,0x7537,0x7df0,0xl78e,0x7ef6,0x373d,0x3d2 

3 ,0x2b 1 4,0x5069,0x 1 d90,0x6bb6,0x4828,0x79e9,0x5ca0,0x5e34,0x2c5 1 ,0x3078,0x 1 9d3 ,0x 1 637,0x5 28c,0 

Xl4f9,0xl9a2,0xl239,0x6f93,0x6e01,0x23f8,0x3333,0x4eff,0x088a,0xl50d,0x0d70,0x24db,0x2b28,0x49e 

0,0xl9ef,0x2673,0x24f0,0x4502,0xlab3,0x6a69,0x7203,0x0ale,0x4991,0xlab3,0xlf38,0xl86a,0x4da3,0x 

Ib0a,0x7f58,0x6a69,0x5055,0x0294,0x634d,0x0e5d,0x2dff,0x7551,0x31fd,0x7259,0x0f95,0x7148,0x223 

0,0xl3cd,0x35f3,0x29bc,0x5bf2,0x40f8,0x3d6e,0x2615,0x3el9,0x4604,0x7203,0x4564,0x3f9c,0x483f,0x 

6183,0x06bl,0x77ee,0xlecc,0x0283,0x3977,0x0a6f,0x7d96,0x2acb,0x7c2f,0x0745,0x2389,0x5cfa,0x4b5f, 

0x2e88,0x6732,0x4675,0x7eac,0x3595,0x766b,0x4558,0x5f9a,0x44dd,0x5d7f,0xl0dc,0x3009,0x7788,0x4 

573,0x52d6,0x712e,0x7f02,0xlf49,0xl488,0x52fd,0x77d2,0x5470,0xl51a,0x74b2,0x059c,0x4f6d,0x3009, 

0x6006,0x637 1 ,0x42 1 d,0x6d07,0x6a69,0x224 1 ,0x72 1 4,0x4c26,0x4abc,0x4 1 30,0x20e9,0x0caf ,0x0fbe,0x4 

e8e,0x0a6f,0x44ca,0x2874,0x2acb,0x36b8,0x4247,0x7eca,0x27el,0x08c7,0x36c9,0x06fc,0x6e2a,0x4991, 

0x4flc,0x5761,0x05c6,0x3595,0x5e6e,0x38d9,0x0311,0xlb7b,0x0fa9,0x751c,0x6b9d,0x2b65,0x27bb,0x2 

aad,0x7080,0x47bd,0xl7b2,0x7ab5,0x500f,0x51al,0x2575,0x44ca,0xldf6,0x4df9,0x4f6d,0x0e3 

0x4604,0x20b3,0x519d,0xl3cd,0x20c2,0x2b4e,0x0708,0x40d3,0x6317,0x374c,0x0c84,0x32fb,0x427b,0x 

02f2,0x2de8,0x4b2e,0x57 1 0,0x004d,0x 1 9c4,0x6fe2,0x597 1 ,0x750b,0x034b,0x4558 ,0x0734,0x62b9,0x4ec 

3,0x01 92,0x40f 8,0x2504,0x0432,0x 1 78e,0x2aba,0x65fc,0x58e3 ,0x574a,0x7 1 74,0x3bdf ,0x2098,0x64 If , Ox 

670e,0x2a91,0x0ce2,0x573b,0x2f57, 

0x2673,0x52fd,0x3044,0x70bc,0x572c,0x0066,0x2dc3,0xlc4f,0x4638,0x2ea3,0x0fcf,0x417d,0x62ae,0xl9 

C4,0x3cbl,0x453e,0x6935,0x0ale,0x5c8b,0x5a77,0x0779,0x6a55,0x221b,0x4662,0x748e,0x6fb8,0x6719, 

0x08ec,0x4b39,0x4247,0x427b,0x6cf3,0xll59,0x668b,0x7546,0x4f20,0x301e,0x4638,0x2dc3,0x761a,0x7. 

499,0x4c26,0x20d5,0x4236,0x65c0,0x4c31,0x7b41,0x27ac,0x2c37,0x3e68,0x73ba,0xlbld,0x6006,0x36c 

9,0x781d,0x0cf5,0x633c,0x77a3,0x2658,0xl78e,0x7836,0x20d5,0x208f,0x4141,0x6922,0x2eee,0x3cfc,0x 

01f4,0x20a4,0x767c,0x2d8e,0x5bf2,0x5bbf,0x760d,0x2241,0x210a,0x6cf3,0x3044,0x68ea,0xldac,0x08b6 

,0x0d2a,0x3e7f,0x7af8,0x2c7a,0x73cb,0x3960,0x52d6,0x0e5d,0x5all,0x29ab,0x7cl3,0x73e0,0x6285,0x4 

9cb,0x08b6,0x6a24,0x2e9f ,0x695 3 ,0x24e7,0x2 1 6c,0x6366,0x484e,0x07 1 f,0x4c57,0x57 1 0,0x0bd6,0x409e, 

0x74e8,0x7272,0x7af8,0x3b92,0x2bl4,0x5d0e,0x35f3,0x3324,0x2ea3,0xlfl3,0xl66d,0x5335,0x2f57,0x5 

43d,0x4c6b,0x4ada,0x4c7c,0x56f3,0x2acb,0x5353,0xl3e6,0x0ale,0x2863,0xl56b,0x24db,0x6d61,0x572c, 

0x545b,0x7b30,0x66ed,0x3e54,0x221b,0x3a5a,0x02bf,0x337e,0x4eb2,0xldbb,0x5b94,0x3906,0x4662,0x 

3fc6,0x0425,0x2b59,0xl3e6,0x5e79,0x3bb9,0x4814,0x7386,0x5b83,0x097e,0x4986,0x2c0b,0x5033,0x66 

ed,0x4c57,0x375b,0xll03,0x0ff3,0x097e,0x689b,0x5966,0x301e,0x02e5,0x61d9,0x059c,0x595a,0x47aa,0 

X4c31,0x77c5,0x0d01,0x373d,0x0924,0x61f2,0x2bl4,0x3044,0x5bf2,0x31d6,0x2f6b,0x0d5b,0x2538,0x73 

91,0xl9a2,0x5d32,0x51ec,0x3342,0x38f2,0x4604,0x6a69,0xl81b,0x2f57,0x6a24,0x2673,0x70da,0x216c, 

0xll4e,0x0fcf,0xl3e6,0x5917,0x7ddb,0xl9a2,0x36f5,0x529b,0x73dc,0x500f,0x52a7,0xl9d3,0x01W 

3e,0x7265,0x0360,0x58ae,0x02e5,0x668b,0x7f58,0x52b0,0x003c,0x7c49,0x0d70,0x2c37,0x66a0,0x5b83, 

0x2dc3,0x528c,0x 1 87d,0x2980,0x500f,0x595a,0x3ffa,0x43a4,0x0283 ,0x70bc,0x 1 274,0x 1 99e,0x7f 1 5,0x3 8 

83,0x595a,0x2db2,0x602d,0x2629,0x77d2,0x689b,0x301e,0x5344,0xl60b,0x6445,0x52d6,0x2136,0x766b 

,0x4250,0x337e,0x787b,0x23ef,0x4c7c,0x0e2c,0x51fb,0x3dlf,0x2c20,0x593c,0x3bf4,0x0294,0x0a35,0x4 

Ilb,0x66ed,0xl205,0x7499,0x6978,0x6e5b,0x5322,0x5ca0,0x4221,0x2af7,0x27el,0x2787,0x5353,0x0066 

,0x62b9,0x0e2c,0xll4e,0x7386,0x5378, 
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0x6a69,0x337e,0x4247,0x 1 25f ,0x49e0,0x 1 1 72,0x285f,0x23b5,0x0fe4,0x5f9a ) 0x0caf,0x67 1 9,0x5 1 b6,0x5e 

79,0x285f ) 0x05ed,0x2ec5,0x0fa9,0x68cl,0x507e,0x518a,0x7097 ) 0x6922,0x7b41,0x2ef9 > 0x0d5b > 0x0e07,0 

X47aa,0x3911,0x0933,0x211d,0x27f6,0x2256,0x4089,0x6732,0x7265,0x2eee,0x723f,0x6011,0xl3bc,0xl5 

7c,0x7eel,0x7386,0x0a44,0x0e2c,0x4247 ) 0x6935,0x3a66,0x6ff5,0x7272,0x0fa9,0x5776,0x4c0d,0x0a78,0 

X4649,0x217b,0x36c9,0x058b,0x2eb4,0x06eb,0x62f4,0x420a,0x7148,0xl81b,0x2c51,0x5024 ; 0xl9b5,0x4 

b74 ) 0x6ccf,0x4638,0x73ba ( 0x6ff5,0x62c8,0x49ba ) 0x40c4,0x593c,0x689b,0x2f31,0x0e07,0x44el,0x0d3d, 

0x7b30,0x003c,0x4675,0x0a35,0x076e,0x24e7,0x4ee8,0x31ea,0x51b6,0xla98,0x465e,0x5cb7,0x6fde,0x2 

4aa,0x3a5a ) 0x06c0,0x0e07,0xl3fl,0x5ced,0x49f7,0x4502,0x4558,0x27dd,0x43d5,0x74ff,0x345d,0x798f,0 

Xl263,0x2aad,0x0708,0x3d6e ; 0x6909,0x252f,0x2ae0,0xlf04,0x4502,0x62ae,0xl651,0x27el,0x3fa0,0x4f3 

7,0x3ffa,0x7c49,0x6fe2,0x756d,0x4c40,0x7aa2,0x723f,0x0caf ; 0x0d70,0x4141,0x31cl,0x73dc,0x77c5,0x5 

Cb7 ( 0x66c6,0xl263,0xl091,0x4b2e ( 0xlf2f,0x3d79,0x7ac4,0x5feb,0x3ffa,0x68ea,0x40d3,0x318c,0x2575,0 

X31cl ( 0x5d54 > 0x73cb,0x395c,0xlee7,0x74ff,0x507e,0x7eel ( 0x4558,0x36af,0x4865,0x56a9,0x7eel,0x65b 

I,0xl091,0x51ec,0x3410,0x3a00 ( 0x696f ( 0x6fde,0xla8f,0x35a9,0xlac2,0x0708,0x6e4c,0x319b,0xl651,0x 

344a,0xlc4f,0x0c93,0xl4c5,0x7b27,0x4558,0xlf2f,0x786c,0x01c8,0x4f46,0x2e88,0x36e2,0x5ca0,0x7dcc, 

0x646e,0x24bd,0x373d,0x65d7,0xlb47,0x3911,0x6909,0x7de7,0xl263,0x4e8e,0x4e8e,0x44f6,0x3a2b,0x6 

300,0xlebd,0xl9ef,0xl67a,0x74d4 ( 0x43e9,0x6bal,0xle96,0x32c7,0xlf38,0x05fa,0x4502,0x2549,0x3410, 

0x6935 ,0x 1 620,0x3977,0x798f,0x3b92,0x034b,0x3a5a,0x0fd8,0x If04,0x4b5f ,0x56a9,0xl 7b2,0x5d43,0x 1 

a98,0x27f6,0x750b,0x0432,0x56be,0x49dc,0x24aa,0x62c8,0x4127,0xlc64,0x7c04,0x5d25,0x5be5,0x6fe2, 

0x5353,0x6732,0x43d5,0x0e07,0x74ff,0x31ea,0x66b7,0x409e,0x6922,0xl99e,0x5ba8,0x05ed,0x411b,0x7 

b41,0x40d3,0x47cc,0x5d54,0x6fe2,0x0e4a,0x05b7,0x66c6,0x6423,0x7daa,0x4398,0x3582,0x2c7a,0x6bec, 

0x5cdl,0x7259,0x4flc,0x20d5,0x3bb9,0x3fdl ; 0x27dd,0x5e08,0x0c93 ; 0x395c,0xl651,0x088a,0x47cc,0x3 

476,0x4865,0x31cl,0x7aef, 

0x7ac4,0x43c2,0xla98,0x4f37 ) 0x47bd,0x5ced,0x77b4,0x7551,0x4dc5,0x756d,0x5cb7,0x6d3b,0x44f6,0x7 

9a4,0x723f,0x3bae,0x3767,0x5971,0x2eb4,0x7c49,0x2dd4,0x342c,0x5cfa,0x7aa2,0x0d70,0xl263,0x3e43, 

0x4089,0x0a09,0xl7ff,0x20e9,0x3369,0x7a89,0x77d2,0x4613,0x0cb8,0x58df,0x7c49,0x6060,0x74ff,0x61 

d9,0xla8f,0x5fbl,0x691e,0x38f2,0x7df0,0x08d0,0x47bd,0x6b8a,0x766b,0xl87d > 0x6d5d,0x438f,0x61d9,0 

X7dbd,0xl620,0x4ed4,0x3a00,0x5917,0x4487,0x7847,0xl646,0x52b0,0xl0e0,0xlb47,0x05a0,0x438f,0x3f 

fa,0x02f2,0x3e0e,0x4662,0xlf5e,0x0468 ) 0x0a09,0x6060,0x2575 ) 0x0723,0x2481,0x2b03,0x79e9,0x6d07,0 

X0311,0x5a2d,0x66fa,0x61f2,0x08d0,0xl0ba,0x0425,0x0bfd,0x542a,0x6d4a,0x61bf,0x3bdf ) 0x2121,0x212 

I ) 0x5d25,0x3767,0xlebd,0x0a78,0x6e01,0x6fb8,0x73cb,0x528c,0x23c4,0xla8f,0x646e,0x409e,0x66c6,0x 

0283 ) 0x2adc,0x3e32,0x5776,0x73ba,0x696f,0x282e,0x0d70,0xll4e,0x4c57 ( 0x0el0,0x3716,0x2da5,0x019 

2 ( 0xl56b ; 0x65c0,0x3701,0x6d2c,0xl531,0x4649,0xll59,0x040e,0x4cla,0x7f58 ( 0x7ebb,0x0ba7,0x3fa0,0x 

5f8d,0x2a86,0x5892,0x5bd9,0x6978,0x 1 3e6,0x2098,0x32a 1 ,0x6c82,0x Iae9,0x394b,0x069a,0x208f ,0x287 
4,0x3476,0x0b8c,0x5fbl,0xl87d,0x20d5,0x2389,0x3fdl,0x31b0,0x641f,0xl66d,0x35e4,0x2c46,0x6a55,0 

x372a,0x6bb6,0x3894,0x40ef ,0x739 1 ,0x4e99,0x68ea,0x5a60,0xl 9b5,0x24bd,0x4f 5 1 ,0x 16 lc,0x32fb,0x 16 
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Annex C 

(informative) 

Example MAC common part sublayer service definition 



C.1 MAC service definition 

This annex describes the services between the MAC and the CSs. This is a logical interface. As such, the 
primitives described are informative. Their purpose is to describe the information that must necessarily be 
exchanged between the MAC and the CSs to enable each to perform its requirements as specified in the 
remainder of this document. This subclause does not impose message formats or state machines for the use 
of these primitives. 

In a layered protocol system, the information flow across the boundaries between the layers can be defined 
in terms of primitives that represent different items of information and cause actions to take place. These 
primitives do not appear as such on the medium (the air interface) but serve to define more clearly the 
relations of the different layers. The semantics are expressed in the parameters that are conveyed with the 
primitives. 

C.1 .1 MAC service definition for PMP 
C.1 .1.1 Primitives 

The IEEE 802.16 MAC supports the following primitives at the MAC SAP, to support services between the 
MAC and the CSs in PMP mode. 

MAC_CREATE_SERVTCE FLOW.request 
MAC_CREATE_SERVICE FLOW, indication 
MAC_CREATE_SERVICE FLOW.response 
MAC_CREATE_SERVICE FLOWxonfirmation 

MAC_CHANGE_SERVICE FLOW.request 
MAC_CHANGE_SERVICE FLOW.indication 
M AC_CH ANGE.SERVICE FLOW.response 
MAC_CHANGE_SERVICE FLOWxonfirmation 

MAC_TERMINATE_SERVICE FLOW.request 
MAC_TERMINATE_SERVICE FLOW.indication 
MAC_TERMINATE_SERVICE FLOW.response 
MAC_TERMINATE_SERVICE FLOWxonfirmation 

MAC_DATA.request 
MAC_DATA.indication 

The use of these primitives to provide peer communication is shown in Figure C.1. The initial request for 
service from a higher layer is provided by the "request" primitive. When this request is sent across the air 
link to the peer MAC, it generates an "indicate" primitive to inform the peer CS of the request; the 
convergence entity responds with a "response" to the MAC. Again this is sent across the air link to the MAC 
on the originating side, which sends a "confirm" primitive to the original requesting entity. 
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Figure C.1— Use of primitives to request service of MAC and generate response 

In some cases, it is not necessary to send information to the peer station and the "confirm" primitive is 
issued directly by the MAC on the originating side. Such cases may occur, for example, when the request is 
rejected by the MAC on the requesting side. In cases where it is necessary to keep the other side of the link 
informed, an unsolicited "response" may be sent, in turn leading to the generation of an unsolicited 
"confirmation" for benefit of the CS. 

For actions other than DATA.request and DATA. indication, the initiating CS sends a REQUEST primitive to 
its MAC. The initiating side MAC sends the appropriate Dynamic Service Addition, Change, or Deletion 
(DSx) Request message (see 6.3.14.7.1 and 6.3.14.8) to the receiving MAC. The noninitiating side MAC 
sends an INDICATION primitive to its CS. The noninitiating CS responds with a RESPONSE primitive, 
stimulating its MAC to respond to the initiating side MAC with the appropriate DSx Response message. The 
initiating side MAC responds to its CS with a CONFIRMATION primitive and, if appropriate, with the 
appropriate DSx Acknowledge message. At any point along the way, the request may be rejected (for lack of 
resources, etc.), terminating the protocol. 

C.1 .1.1.1 MAC_CREATE_SERVICE FLOW.request 
C.1 .1.1.1.1 Function 

This primitive is issued by a CS entity in a BS or SS unit to request the dynamic addition of a connection. 
C.1 .1.1.1.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_CREATE SERVICE FLOW.request 
( 

MAC Address 

scheduling service type, 

convergence sublayer, 

service flow parameters, 

payload header suppression indicator, 

encryption indicator, 

Packing on/off indicator, 

Fixed-length or variable-length SDU indicator, 

SDU length (only needed for fixed-length SDU connections), 

CRC request, 

ARQ parameters, 

sequence number 

) 
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For connection requests initiated from a BS, the 48-bit MAC Address value identifies the SS with which the 
connection is to be established. The parameter has no significance for connection requests initiated from an 
SS. 

The scheduling service type (see 6.3.5) is one of the following: Unsolicited grant service (UGS), real-time 
polling service (rtPS), non-real-time polling service (nrtPS), and Best Effort (BE) service. 

The convergence sublayer parameter indicates which CS handles data received on this connection. If the 
value is zero, then no CS is used; other values for specific CSs are given in 1 1.13.19. 

The service flow parameters include details on such issues as peak and average rate, or reference to a service 
class. These parameters are the same as those in the DSC Request MAC Management message. 

The payload header suppression indicator specifies whether the SDUs on the service flow are to have their 
headers suppressed. 

The encryption indicator specifies that the data sent over this connection is to be encrypted, if ON. If OFF, 
then no encryption is used. 

The packing on/off indicator specifies whether packing may be applied to the MAC SDUs on this 
connection. A value of ON means that packing is allowed for the connection. 

The fixed-length or variable-length SDU indicator specifies whether the SDUs on the service flow are fixed- 
length or variable-length. 

The SDU length specifies the length of the SDU for a fixed-length SDU service flow. The parameter has no 
significance for a variable length SDU service flow. 

Cyclic redundancy check (CRC) request, if ON, requests that the MAC SDUs delivered over this connection 
are transported in MAC PDUs with a CRC added to them. 

The ARQ parameters are: whether or not ARQ is used for the connection, maximum retransmission limit, 
and acknowledgment window size. 

The sequence number is used to correlate this primitive with its response from the BS via the MAC. 
C.1 .1 .1 .1 .3 When generated 

This primitive is generated by a CS of a BS or SS unit to request the BS to set up a new connection. 
C.1 .1 .1 .1 .4 Effect of receipt 

If the primitive is generated on the SS side, the receipt of this primitive causes the MAC to pass the request 
(in the form of a DSA-REQ message) to the MAC entity in the BS. The SS MAC remembers the correlation 
between sequence number and the requesting convergence entity. 

If the primitive is generated on the BS side, the BS checks the validity of the request and, if valid, chooses a 
CID and includes it in the DSA-REQ message (6.3.14.9.3) sent to the SS. This CID shall be returned to the 
requesting CS via the CONFIRM primitive. If the primitive originated at the SS, the actions of generating a 
CID and authenticating the request are deferred to the INDICATION/RESPONSE portion of the protocol. 
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C.1J.1.2 MAC_CREATE_SERVICE FLOW.indication 
C.1 .1.1.2.1 Function 

This primitive is sent by the noninitiating MAC entity to the CS, to request the dynamic addition of a 
connection in response to the MAC receiving a DSA-REQ message. If the noninitiating MAC entity is at the 
BS, an SFID and possibly CID are generated and the request is authenticated. 

C.1 .1.1.2.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_CREATE_SERVICE FLOW.indication 
( 

service type, 
convergence sublayer, 
service flow parameters, 
sequence number 

) • . 

Parameters: see MAC_CREATE_SERVICE FLOW.request. The encryption and CRC flags are not delivered 
with the.indication primitive since they will have already been acted on by lower layers, to decrypt the data 
or to check a CRC, before the MAC SDU is passed up to the CS. 

C.1 .1 .1 .2.3 When generated 

This primitive is generated by the MAC of the noninitiating side of the protocol when it receives a DSA-REQ 
message from the initiating side of the connection. 

C.1 .1 .1 .2.4 Effect of receipt 

When the CS receives this primitive, it checks the validity of the request from the point of view of its own 
resources. It accepts or rejects the request via the MAC_CREATE_SERVICE FLOW.response primitive. 

If the connection request was originated on the SS side, the BS sends the CID to the SS side in this 
RESPONSE primitive. Otherwise, if the origin was the BS, the RESPONSE contains the CID contained in 
the DSA header bearing the indication. 

C.1. 1.1. 3 MAC_CREATE_SERVICE FLOW.response 

C.1 .1.1.3.1 Function 

This primitive is issued by a noninitiating MAC entity in response to a MAC_CREATE_SERVICE 
FLOW.indication requesting the creation of a new connection. 
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C.1 .1.1.3.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_CREATE_SERVICE FLOW.response 
( 

Connection ID, 
response code, 
response message, 
sequence number, 
ARQ parameters 
) 

The Connection ID is returned to the requester for use with the traffic specified in the request. If the request 
is rejected, then this value shall be ignored. 

The response code indicates success or the reason for rejecting the request. 

The response message provides additional information to the requester, in type/length/value (TLV) format: 

The sequence number is returned to the requesting entity to correlate this response with the original request. 

The ARQ parameters are: whether or not ARQ is used for the connection, maximum retransmission limit 
and acknowledgment window size. 

C.1 .1.1. 3.3 When generated 

This primitive is generated by the noninitiating CS entity when it has received a MAC_CREATE_SERVICE 
FLOW.indication. 

C.1 .1.1 .3.4 Effect of receipt 

The receipt of this primitive causes the MAC to send the DSA Response (DSA-RSP) message to the 
requesting MAC entity. Once the DSA Acknowledgment (DSA-ACK) is received, the MAC is prepared to 
pass data for this connection on to the air link. 

C.1 .1.1 .4 MAC_CREATE_SERVICE FLOW.confirmation 

C.1 .1.1 .4.1 Function 

This primitive confirms to a convergence entity that a requested connection has been provided. It informs 
the CS of the status of its request and provides a CID for the success case. 

C.1 .1.1.4.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_CREATE_SERVICE FLOW.confirmation 
( 

Connection ID, 
response code, 
response message, 
sequence number 
) 
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Parameters: see MAC_CREATE_SERVICE FLOW.response. 
C.1 .1.1-4.3 When generated 

This primitive is generated by the initiating side MAC entity when it has received a DSA-RSP message. 
C.1 .1.1.4.4 Effect of receipt 

The receipt of this primitive informs the convergence entity that the requested connection is available for 
transmission requests. 

C.1 .1 .1 .5 Changing an existing connection 

Existing connections may be changed in their characteristics on a dynamic basis to, for example, reflect 
changing bandwidth requirements. The following primitives are used: 

MAC_CHANGE_SERVICE FLOW.request 
MAC_CHANGE_SERVICE FLOW.indication 
MAC_CHANGE_SERVICE FLOW.response 
MAC_CHANGE_SERVICE FLOW.confirmation 

The semantics and effect of receipt of these primitives are the same as for the corresponding CREATE 
primitives. A new CID shall be generated in the case of changing a service flow type from provisioned to 
admitted or active. 

C.1 .1.1.6 MAC_TERMINATE_SERVICE FLOW.request 
C.1 .1.1 .6.1 Function 

This primitive is issued by a CS entity in a BS or SS unit to request the termination of a connection. 
C.1 .1.1.6.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_TERMINATE_SERVICE FLOW.request 

( 

SFID 

) 

The SFID parameter specifies which service flow is to be terminated. 
C.1 .1.1.6.3 When generated 

This primitive is generated by a CS of a BS or SS unit to request the termination of an existing connection. 
C.1 .1.1.6.4 Effect of receipt 

If the primitive is generated on the SS side, the receipt of this primitive causes the MAC to pass the request 
to the MAC entity in the BS via the DSD Request (DSD-REQ) message. The BS checks the validity of the 
request, and if it is valid it terminates the connection. 

If the primitive is generated on the BS side, it has already been validated and the BS MAC informs the SS by 
issuing a DSD-REQ message. 
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C.1.1.1.7 MAC_TERMINATE_SERVICE FLOW.indication 
C.1.1. 1-7.1 Function 

This primitive is issued by a the MAC entity on the noninitiating side to request the termination of a 
connection in response to the receipt of a DSD-REQ message. 

C.1.1. 1.7.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_TERMINATE_SERVICE FLOW.indication 
( 

SFID 

) 

The SFID parameter specifies which service flow is to be terminated. 
C.1 .1 .1 .7.3 When generated 

This primitive is generated by the MAC when it receives a DSD-REQ message to terminate a connection, or 
when it finds it necessary for any reason to terminate a connection. 

C.1.1. 1.7.4 Effect of receipt 

If the protocol was initiated by the SS, when it receives this primitive, the BS checks the validity of the 
request. In any case, the receiving CS returns the MAC_TERMINATE_SERVICE FLOW.response primitive 
and deletes the SFID from the appropriate polling and scheduling lists. 

C.1.1. 1.8 MACTERMINATE_SERVICE FLOW.response 

C.1.1. 1.8.1 Function 

This primitive is issued by a CS entity in response to a request for the termination of a connection. 
C.1 .1.1. 8.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_TERMINATE_SERVICE FLOW.response 
( 

SFID, 

response code, 
response message 
) 

The SFID is returned to the requesting entity. 

The response code indicates success or the reason for rejecting the request. 

The response message provides additional information to the requester, in TLV format. 
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C.1 .1 .1 .8.3 When generated 

This primitive is generated by the CS entity when it has received a MAC_TERMINATE_SERVICE 
FLOW.indication from its MAC. 

C.1 .1 .1 .8.4 Effect of receipt 

The receipt of this primitive causes the MAC to pass the message to the initiating side via the DSD Response 
(DSD-RSP) message. The initiating MAC in turn passes the CONFIRM primitive to the requesting 
convergence entity. The convergence entity shall no longer use this CID for data transmission. 

C.1 .1.1 .9 MAC_TERMINATE_SERVICE FLOW.confirmation 

C.1 .1.1.9.1 Function 

This primitive confirms to a convergence entity that a requested connection has been terminated. 
C.1 .1.1.9.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MACJTERMINATELSERVICE FLOW.confirmation 

( 

SFID, 

response code, 
response message 
) 

Parameters: see MAC_TERMINATE_SERVICE FLOW.response. 
C.1 .1.1.9.3 When generated 

This primitive is generated by the MAC entity when it has received a DSD-RSP message. 
C.1 .1.1.9.4 Effect of receipt 

The receipt of this primitive informs the convergence entity that a connection has been terminated. The 
convergence entity shall no longer use this CID for data transmission. 

C.1.1.1.10 MAC_DATA. request 

C.1 .1.1.10.1 Function 

This primitive defines the transfer of data to the MAC entity from a CS SAP 
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C.1 .1.1.11 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_DATA.request 

( 

Connection ID, 

length, 

data, 

discard-eligible flag 

The Connection ID parameter specifies the connection over which the data is to be sent; the service class is 
implicit in the Connection ID. 

The length parameter specifies the length of the MAC SDU in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The discard-eligible flag specifies whether the MAC SDU is to be preferentially discarded by the scheduler 
in the event of link congestion and consequent buffer overflow. 

The encryption flag specifies that the data sent over this connection is to be encrypted, if ON. If OFF, then 
no encryption is used. 

C.1 .1.1.11.1 When generated 

This primitive is generated by a CS whenever a MAC SDU is to be transferred to a peer entity or entities. 
C.1 .1.1.11.2 Effect of receipt 

The receipt of this primitive causes the MAC entity to process the MAC SDU through the MAC and to pass 
the appropriately formatted PDUs to the PHY Transmission Convergence sublayer for transfer to peer MAC 
entities, using the CID specified. 

C.1 .1.1.12 MACJMTA.indication 

C.1 .1.1.12.1 Function 

This primitive defines the transfer of data from the MAC to the CS. The specific CS to receive the indicate 
message is implicit in the CID. 

C.1 .1 .1 .1 2.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_D ATA. indication 
( 

Connection ID, 

length, 

data, 

reception status, 
) 



Copyright ©2004 IEEE. All rights reserved. 



849 



IEEE Std 802.16-2004 



IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKS— PART 16: 



The Connection ID parameter specifies the connection over which the data was sent. 

The length parameter specifies the length of the data unit in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The reception status parameter indicates transmission success or failure for those PDUs received via the 
MAC_DATA.indication. 

C.1 .1.1 .12.3 When generated 

This primitive is generated whenever an MAC SDU is to be transferred to a peer convergence entity or 
entities. 

C.1 .1.1.12.4 Effect of receipt 

The effect of receipt of this primitive by a convergence entity is dependent on the validity and content of the 
MAC SDU. The choice of CS is determined by the CID over which the MAC SDU was sent. 

C.1 .1 .2 MAC service stimulation of DSx messages 

This subclause describes the logical interaction between the MAC Service primitives and the DSx messages. 

The sequence of logical MAC SAP events and the associated actual MAC events effecting a CS-stimulated 
connection creation are shown in Figure C.2. 
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The sequence of logical MAC SAP events and the associated actual MAC events effecting a CS stimulated 
connection change are shown in Figure C.3. 
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The sequence of logical MAC SAP events and the associated actual MAC events effecting a CS stimulated 
connection deletion are shown in Figure C.4. 
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C.1.2 MAC service definition for Mesh 
C.1.2.1 Primitives 

The IEEE 802.16 MAC supports the following primitives at the MAC SAP in Mesh mode: 

MAC_CREATE_SERVICE FLOW.indication 

MAC_CHANGE_SERVICE FLOW.indication 

MAC_TERMINATE_SERVICE FLOW.request 
MAC_TERMINATE_SERVICE FLOW.indication 

MAC_DATA.request 
MAC_DATA.indication 

MAC_FORWARDING_UPDATE.request 
MAC_FORWARDINGJJPDATE.indication 

In Mesh mode none of the actions cause the initiating CS to send a REQUEST primitive to its MAC. They 
are either indications of the results from the processes handled by the MAC CPS management entity, or data 
delivery actions needed to convey information to the peer CS. 

C.1 .2.1.1 MAC_CREATE_SERVICE FLOW.indication 

C.1 .2.1.1.1 Function 

This primitive is issued by a MAC entity to the CS, to report a new link established to a neighbor node. 
C.1 .2.1.1.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_CREATE_SERVICE FLOW.indication 
{ 

CID 

max length, 

service flow parameters, 
encryption flag 

» 

The CID is the Connection ID in Mesh as conveyed in the generic MAC header. 

The max length parameter specifies the maximum length of SDUs that are allowed over the link. 

The service flow parameters include information on 

— Data rate (Mb/s) 

Data rate associated with the profile for the physical link over which the connection is created. 

— Transmit power (dBm) 

Transmit power at the antenna port for the physical link over which the connection is created. 

— Estimate of packet error rate for 256-byte packets 

Estimate of PER for the physical link over which the connection is created. 
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The encryption flag specifies that the data carried over this link is encrypted, if ON, If OFF, then no 
encryption is used. 

C.1 .2.1.1.3 When generated 

This primitive is generated whenever a new link has been established to a neighbor node. 
C.1 .2.1.1.4 Effect of receipt 

The receipt of the primitive is an indication to the CS that a link to the given neighbor node is up and can be 
used for data delivery. 

C.1 .2.1 .2 MAC_CHANGE_SERVICE FLOW.indication 
C.1 .2.1.2.1 Function 

This primitive is issued by a MAC entity to the CS, to report new parameters of an existing link to a 
neighbor node. 

C.1 .2.1 .2.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_CHANGE_SERVICE FLOW.indication 
{ 

cro, 

max length, 
service parameters, 
encryption flag 
} 

The CID is the Connection ID in Mesh as conveyed in the generic MAC header. 

The max length parameter specifies the maximum length of SDUs that are allowed over the link. 

The service parameters include information on 

— Target data rate for the link in Mb/s 

— Transmit energy for the link 

— Estimate of packet error rate for 256 byte packets 

The encryption flag specifies that over this link encryption is possible, if ON, If OFF, then no encryption is 
possible. 

C.1 .2.1 .2.3 When generated 

This primitive is generated whenever parameters of an existing link has changed. 
C.1 .2.1 .2.4 Effect of receipt 

The CS shall take into account new link parameters in the use of the link. 
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C.1 .2.1.3 MAC_TERMINATE_SERVICE FLOW.request 

i 

C.1 .2.1.3.1 Function 

This primitive is issued by a CS, to terminate an existing link to a neighbor node. 
C.1 .2.1.3.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_TERMINATE_SERVICE FLOW.request 
{ 

CID 

} 

The CID is the Connection ID in Mesh as conveyed in the generic MAC header. 
C.1 .2.1.3.3 When generated 

This primitive is generated to bring down an existing link to a neighbor node. 
C.1 .2.1 .3.4 Effect of receipt 

The receipt of the primitive causes the MAC to terminate the connection and report that to the MAC entity in 
the neighbor the link was to. 

C.1 .2.1.4 MAC_TERMINATE_SERVICE FLOW.indication 
C.1 .2.1.4.1 Function 

This primitive is issued by the MAC entity of the noninitiating side to indicate termination of the link to a 
neighbor node. 

C.1 .2.1.4.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_TERMINATE_SERVICE FLOW.indication 
{ 

CID, 
} 

The CID is the Connection ID in Mesh as conveyed in the generic MAC header. 
C.1. 2.1. 4.3 When generated 

This primitive is generated by the MAC when it receives an indication in a Mesh Network Configuration 
(MSH-NCFG) message. 

C.1. 2.1. 4.4 Effect of receipt 

The receipt of the primitive is an indication to the CS that the link to the given neighbor node is down and 
cannot be used for data delivery. 
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C.1 .2.1.5 MAC_DATA.request 
C.1 .2.1.5.1 Function 

This primitive defines the transfer of data to the MAC entity from a CS SAP. 
C.1 .2.1.5.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_DATA.request 
{ 

CID, 

length, 

data, 

encryption flag 
} 

The CID is the Connection ID in Mesh as conveyed in the generic MAC header. 

The length parameter specifies the length of the MAC SDU in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The priority/class parameter embedded in the CID specifies priority class of the MAC SDU. 

The reliability parameter embedded in the CID specifies maximum number of transmission attempts at each 
link. 

The drop precedence parameter embedded indicates relative MSDU dropping likelihood. 

The encryption flag specifies that the data sent over this link is to be encrypted, if ON. If OFF, then no 
encryption is used. 

C.1 .2.1.5.3 When generated 

This primitive is generated by a CS whenever an MAC SDU is to be transferred to a peer entity. 
C.1 .2.1.5.4 Effect of receipt 

The receipt of the primitive causes the MAC entity to process the MAC SDU through the MAC and pass the 
appropriately formatted PDUs to the PHY for transfer to the peer MAC entity, using the Node ID specified. 

C.1 .2.1.6 MAC_DATA.indication 

C.1 .2.1.6.1 Function 

This primitive defines the transfer of data from the MAC to the CS. 
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C.1 .2.1.6.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_DATA.request 
{ 

CID 

length, 

data, 

reception status, 
encryption flag 
} 

The CID is the Connection ID in Mesh as conveyed in the generic MAC header. 

The length parameter specifies the length of the MAC SDU in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The reception status parameter indicates transmission success or failure for those PDUs received via the 
MAC_DATA.indication. 

C.1 .2.1.6.3 When generated 

This primitive is generated whenever an MAC SDU is to be transferred to a peer convergence entity. 
C.1 .2.1.6.4 Effect of receipt 

The effect of receipt of this primitive by a convergence entity is dependent on the validity and content of the 
MAC SDU. 

C.1 .2.1.7 MAC_FORWARDING_UPDATE. request 
C.1 .2.1.7.1 Function 

This primitive defines the transfer of the centralized scheduling configuration to the MAC entity from a CS 
SAP in the Mesh BS. 

C.1 .2.1.7.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_FORWARDING_UPDATE.request 
{ 

number of nodes, 

node parameters[number of nodes] 
} 

The number of nodes parameter indicates number of nodes in the scheduling tree of this Mesh BS. 
The node parameters entry shall contain the following information: 

— Node ID: The Node ID parameter indicates the node. 

— Number of children: The number of nodes parameter indicates number of children the given node. 

— Child parameters [number of children] 
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Each child parameters entry shall contain the following information: 

— Child index: The child index indicates index into the list of Node IDs 

— Uplink burst profile: The uplink burst profile indicates burst profile of link to child node 

— Downlink burst profile: The downlink burst profile indicates burst profile of link from child node 

C.1 .2.1.7.3 When generated 

This primitive is generated in the Mesh BS whenever it has changed the schedule tree. 
C.1 .2.1.7.4 Effect of receipt 

The receipt of this primitive causes the MAC to generate a MSH-CSCF message with the given information. 
The message shall be distributed to all the nodes listed in the tree. 

C.1. 2.1. 8 MAC_FORWARDING_UPDATE.indication 

C.1 .2.1.8.1 Function 

This primitive defines the transfer of the centralized scheduling configuration from the MAC to the CS. 
C.1 .2.1 .8.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MAC_FORWARDING_UPDATE.indication 
{ 

Node ID self 
number of nodes, 




The Node ID self indicates the Node ID of the node itself. 

The number of nodes parameter indicates number of nodes in the scheduling tree of this Mesh BS. 
The node parameters entry shall contain the following information: 

— Node ID: The Node ID parameter indicates the node. 

— Number of children: The number of nodes parameter indicates number of children the given node. 

— Child parameters [number of children] 

Each child parameters entry shall contain the following information: 

— Child index: The child index indicates index into the list of Node IDs 

— Uplink burst profile: The uplink burst profile indicates burst profile of link to child node 

— Downlink burst profile: The downlink burst profile indicates burst profile of link from child node 

C.1 .2.1 .8.3 When generated 

This primitive is generated by the MAC at all the nodes, which have received the MSH-CSCF message, 
when new centralized schedule with revised schedule tree takes effect. 

C.1 .2.1 .8.4 Effect of receipt 

The receipt of this primitive synchronizes the forwarder and MAC scheduler to routing changes. 
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